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

Hart's Antler bhartsho at yahoo.com
Mon May 23 07:58:49 CEST 2011


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
> 


More information about the Bf-committers mailing list