[Bf-committers] Some ideas to improve the "Add-Ons" section

[Jonathan Smith]

Features 3 sounds great. I've also been thinking of the benefits of having
an area for custom parameters for each script (although they only would need
to be shown if the script required them, not all scripts would require
them). A great use case for me would be the ability to enable the dynamic
spacebar menu for different spaces using checkboxes in the scripts
parameters, instead of writing a different script for each space (which is
what I'd have to do now).

Feature 4 is not such a great idea though, because if the updated script
contains new parameters in the custom area, then the old data would not be
able to apply.

The other two features might be nice if they were implemented correctly,
however it doesn't seem like Blender is lacking to much in the area they
intend to address.

Cheers,
Jonathan


On Sun, May 15, 2011 at 8:45 PM, Jass <gaia.clary at machinimatrix.org> wrote:

> Hi.
>
> Right now Blender add-ons can only be installed and
> activated/deactivated. I propose to add 4 more features:
>
>
> ============================================================
> Feature 1: Allow for deinstalling a deactivated module.
> ============================================================
>
> Sometimes i install something to test it, but later decide
> to remove it again. In that case i also want to scratch it
> completely from my Blender. I know that i simply can go to
> the application-data folder and remove the addon from there.
> But i think, this is an inconvenient way to proceed.
>
>
> ============================================================
> Feature 2: Add an "update" button in the module descriptor:
> ============================================================
>
> Right now the Module descriptor contains 2 buttons:
>
>   - Link to the Wiki
>   - Report a Bug
>
> What about adding a third button:
>
>   - Check for Update
>
> When clicked,  a URL is called (defined in the module) which returns
> the newest available version of the module. If the returned version
> matches the installed version, then display:
>
>   "your module is up to date"
>
> otherwise change the button to:
>
>   - Update to version x.y.z"
>
> If user clicks on the update button, the module gets updated from
> the update-URL (which is also defined in the module). The update URL
> should be allowed to contain cgi-parameters (http-GET request).
>
>
> ============================================================
> Feature 3: Allow to add module customization parameters
> ============================================================
>
> The module descriptor could offer the possibility to add some module
> specific customization informations. So a module could add a list of
> entry fields (checkmarks/buttons/text fields) to the descriptor.
>
> And the user can fill/change the data and the module can use that data
> to control its runtime features (like enable only parts of the module
> or whatever)
>
>
> ============================================================
> Feature 4: Allow for updating instead of reinstalling  a module.
> ============================================================
>
> An addOn module might also contain a "customer area" which may be
> modified (implicitly through the module activities) by the users.
> When we deliver a new version of the module, then at the moment
> any old configuration/customization would get lost.
>
> IMHO the simplest way to solve this:
>
> Put all customer data to a "module custom area" which remains
> unchanged when a module is reinstalled.  And add an API to that
> data so that a module can access this information safely.
>
> Maybe such a feature already exists?
> Then where can i find the API to access/maintain it ?
>
>
> Cheers,
> Gaia
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>