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 <[email protected]> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
