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<[email protected]> wrote: > >> From: mindrones<[email protected]> >> Subject: Re: [Bf-committers] Some ideas to improve the "Add-Ons" section >> To: "bf-blender developers"<[email protected]> >> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
