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

[Aurel W.]

You are essentially asking for full features of a package management
system. However, this would only be possible if we centralize the
distribution and release of scripts in some way.

We already do this to some amount with bundled scripts, which are
released with blender. Those are an official part of blender, even
though some are maintained more by external contributors. Those
scripts will be updated with the blender release itself anyway,
individual release cycles don't make any sense imho.

So we already have something like a central repository for scripts and
we make sure that those are maintained well and work. But we don't
want and can't do this for every existing script out there and
therefore those need to be maintained externally without the use of a
central repository, which allows for updates etc.

aurel

On 15 May 2011 13:45, 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
>