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

[Jass]

Maybe change the list to a table with 3 columns for:

| addon name | installed | last update |

And let the table be sortable by column...

====

 From the ongoing discussion it appears to me that you (the blender coders)
focus on those addon modules which get distributed with blender-releases.

While i was focussing on third party modules which are NOT distributed
with blender releases!  So IMHO no fancy module-management  is needed
for these addons (from blender). Maybe this are 2 separate but related
issues at the end ?

To summarize again my initial post: The most interesting features (for 
me) are:

- Add the ability to deinstall an installed (third party) module
- Add the ability to insert persistent customization data for modules.
   The customization data should persist a blender upgrade and a module
   upgrade (i have no idea if that is easy or complicated to do)

An additional "nice to have" would be

- add an API to query (a third party website) for new versions of an
   addon module, and possibly add a button for retrieving the addon
   directly from a (third party) download server instead of first 
downloading
   from the web, then updating. This would fit nicely into the list of
   buttons: [Wiki], [Bug Report], [Check for Update]

Cheers,
Gaia

Am 23.05.2011 07:58, schrieb Hart's Antler:
> The Addons system badly needs a "recently added" list, that should be the default when going to UserPrefs>Addons.
>
> The most common question i get from users of my addons is "where do i go to enable it".  Even if i put in the addon README UserPrefs>Addons>Somecategory>myaddon, few seem to figure that out and get lost is the long list of addons presented in the Addon panel.
>
> -brett
>
>
>
> --- On Sun, 5/22/11, mindrones<mindrones at gmail.com>  wrote:
>
>> From: mindrones<mindrones at gmail.com>
>> Subject: Re: [Bf-committers] Some ideas to improve the "Add-Ons" section
>> To: "bf-blender developers"<bf-committers at blender.org>
>> Date: Sunday, 22 May, 2011, 1:43 PM
>> Hi!
>>
>> On 05/21/2011 12:31 AM, Doug Hammond wrote:
>>>> - 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.
>>>
>>> I though work in this direction was already under way,
>> I remember discussing
>>> at length
>>> with mindrones about addon metadata, development
>> branches, stable branches,
>>> binary module URLs etc etc...
>>>
>>> What happened to all that effort?
>>
>> It's a bit on hold due to my work on the wiki maintenance
>> and real life
>> small disasters (like having to relocate twice :)
>>
>>
>> Some times ago, when we've setup the new wiki server we
>> have also setup
>> a virtual host for the addon dispatcher application that
>> will distribute
>> updates for trunk/contrib, but also for externals addons,
>> like
>> luxrender, yafaray, gamekit, etc...
>>
>>
>> As Doug said, the design is already setup, see
>> http://wiki.blender.org/index.php/User:Mindrones/Bf-extensions/External_addons
>>
>> All in all we have dsicussed at length, so we know well
>> what to do, it's
>> a matter of doing it. Sorry to be late on that :/
>>
>>
>> As Campbell said, we will need to work on branches, so that
>> if a
>> developer has updates for a blender version that has
>> already been
>> released he will have to commit in branches, here:
>> https://svn.blender.org/svnroot/bf-extensions/branches/
>>
>> If you download a certain version of blender and a
>> developer makes a fix
>> on branch for your revision, you would get notified and
>> download the new
>> version. But it's not that easy because some people develop
>> scripts in
>> the scripts/ dir, so just overwriting the current script
>> with a new one
>> might be undesirable for some people. We need to think
>> about a temp/dev
>> folder to store stuff when we update.
>>
>>
>> About external scripts, there has been a long discussion
>> with Ton in
>> #blendercoders:
>> 1) if a script is developed outside of bf-extensions, like
>> on github or
>> so, BF will only work as mirror at
>> https://svn.blender.org/svnroot/bf-extensions/extern/
>> 1b) no real development would be allowed on
>> bf-extensions/extern/.
>>      - BF would allow developers to make API
>> changes fixes and trivial
>> fixes on bf-extensions/extern, but not more to avoid
>> forking
>>      - externals devs should agree to port these
>> fixes to their external repo
>> 2) of course only GPL-compatible scripts would be
>> distributable via
>> bf-extensions/extern/
>>
>>
>> With all these resctrictions and complications, I agree
>> that this will
>> evolve into a package manager, so it's not that easy to do
>> it quick and
>> dirty.
>>
>> Our goal would be a system like the firefox addons site,
>> but this is a
>> major feature and it has has server-side maintenance
>> implications, so
>> it's not something you develop in blender only.
>>
>>
>> To avoid server-side implications, you should let blender
>> download stuff
>> from wherever you want but according to the discussions we
>> had back
>> then, I doubt BF will allow this on official releases.
>>
>>
>> Hope this has clarifies things a bit :)
>>
>>
>> Regards,
>> Luca
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers