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

Campbell Barton ideasman42 at gmail.com
Fri May 20 19:18:40 CEST 2011


Quick reply on this topic:

- Ability to remove addons (which have been installed to the home
dir), would be good (I'll probably do this one).

- Addons having their own preferences makes sense too, think this is
more a case of using existing python module xml/json/pickle... to
formalize one of them as being preferred & writing some helper
functions to read/write the preferences to the right place giving the
addon name only.
A UI needs to be made available for this too.

- Ability to keep addons in sync/update with an online repo could work
but am wary of this turning into a package manager, we would need to
have a branch for each release so addon devs could work on extension
trunk as well as the release branch so users get updates too.
Since this needs buy-in from existing addon developers I rather leave
this for a bit since addons are being actively added/written/removed
and the addon community is still quite new.

Of course if a developer wants to take this project and start now -
that'd be great and gives some time to develop and test before its in
a release.

On Sun, May 15, 2011 at 12:38 PM, Jass <gaia.clary at machinimatrix.org> wrote:
> I refer to external modules only, aka modules which are developed
> completely independent from blender. IMHO the first 2 features
> make pretty much sense for such external modules:
>
> Feature 1: Allow for deinstalling a deactivated module.
> Feature 2: Add an "update" button in the module descriptor
>
> I do not see where blender would need to setup a central repository
> to support these features as the update process would only involve to
> call 2 URL's (one for checking, the other for retrieving the new module)
> and this would only be done if these URL's actually would be defined
> within the module and the user actually clicks the button(s) ...
>
> IMHO the 3rd feature has nothing to do with package management,
> but with user customization (again usability and user experience here):
>
> Feature 3: Allow to add module customization parameters
>
> And after reading the response from Jonathan, it appears to me that
> having an implementation for feature 3 could even make feature 4
> obsolete:
>
> Feature 4: Allow for updating instead of reinstalling  a module.
>
>
> Cheers,
> Gaia
>
> Am 15.05.2011 14:07, schrieb 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
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list