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

[Damir Prebeg]

I would like to see one more button - "Edit Addon" for quicker access
to the addon code (I know, I can always navigate my self through
folders but why not quicken things).
Also, I think that Import-Export category should be divided in two
separated Import and Export categories because the fact that not all
import-export addons providing both functions and even under File menu
they are having separated sub-menus.
And one more thing but that one is more related to general design of
some pages of User Prefs: Left side with buttons should be separated
from the right side with list of addons and both should be scrollable
(same would be applicable to theme and input pages of user prefs)

Best regards,

Damir

On 23 May 2011 06:01, Daniel Salazar - 3Developer.com <zanqdo at gmail.com> wrote:
> i think adding keywords to addons would be good, Searching for a
> specific addon limmited by its name sometimes isnt the best
>
> Daniel Salazar
> 3Developer.com
>
>
>
> On Sun, May 22, 2011 at 11:58 PM, Hart's Antler <bhartsho at yahoo.com> wrote:
>> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>