Hi Jason, You raise an important point. On bf-committers I stated an assumption that this would not be supported. But I don't think it necessarily needs to be enforced.
The bottom line is that addon writers can enable or break different levels of co-existence between multiple versions of their addon. A clever addon writer could in fact make it possible to enable multiple versions of their addon simultaneously. And, conversely, I imagine an addon writer could write their addon in such a way that enabling even just one version breaks when multiple versions are installed. My intent is simply for this to be supported in Blender, and then it's up to addon writers to write their addons in a way that is friendly to this. --Nathan On Tue, Feb 26, 2013 at 10:40 AM, Jason van Gumster < [email protected]> wrote: > > Nathan Vegdahl <[email protected]> wrote: > > > A topic that has come up over on bf-committers is the possibility of > > supporting multiple co-installed versions of the same addon, without it > > showing up as a conflict in the addon browser. > > A complication I see with this is in the event that the user actually > enables > both (or more) versions of the add-on. Assuming that the add-on(s) make > additions/overrides to the UI in the form of panels, menus, and hotkeys, > there's no easy way to differentiate what UI element belongs to which > version > of the add-on. > > So perhaps I'm stating the obvious, but in order for this to work, a check > should be included to prevent multiple enabled instances of the add-on. The > question then becomes: how does that get implemented and enforced? > > -Jason > _______________________________________________ > Bf-python mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-python >
_______________________________________________ Bf-python mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-python
