[Bf-committers] Some Ideas for a Blender Plugin System

[Yury Baranov]

Dalai, I think addon system has pretty much limited functionality.
1. No modifiers
2. No procedural objects
3. No animation controllers
Every place where addon can't be used and where plugin needs to be used
have a lot of calculations and a lot of "data sending/recieving/sending
back" as a task. I think that's the main reason.
For example, Sapling will be better as a interactive procedural object. But
it's an addon, with all limitations and problems on the board.
And of course need to mention that every plugin basically need 4 versions
(because of its binary nature) - Linux, FreeBSD, Windows(32/64), MacOS X.

2015-11-03 16:14 GMT+03:00 Dalai Felinto <dfelinto at gmail.com>:

> Hi,
>
> I'm missing the main point here which would be, what is the advantage
> of a C/C++ plugin system over the current Python addon interface?
>
> I'm currently developing an addon which relies on an external C++ SDK.
> I got things working with ctypes and C API. It works pretty fine.
>
> Cheers,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2015-11-03 10:59 GMT-02:00 Martin Felke <martin.felke at t-online.de>:
> > Hi, today i wrote down a couple of more thoughts regarding a plugin
> > system. As said earlier, those serve only as discussion starting points
> > and are not meant yet as design principles made out of cement. :)
> >
> > Fat VS Slim Core
> > ----------------
> > - currently we have a fat core which contains all functionality
> >   as monolith
> > - hard to extend and to maintain because it might be everything depends
> >   on everything else
> > - idea: a slim, "bootloader like" core, which handles modules and
> >   plugins registration and deregistration and serves as API Hub (of
> >   existing modules)
> > - modules are not standalone, they communicate via a central core API
> >   Hub so they need the core as well
> > - this way the core can track module APIs and provide a fallback (as
> >   in exception handler) for missing code / functions (if module or
> >   plugin is not present)
> >
> > Modules VS Plugins
> > ------------------
> > - need to distinguish between logical code separation (module) and
> >   "physical" separation (plugin, as in shared library or dll)
> > - group existing core functionality to modules (like, an editor could
> >   be a module, or even a modifier)
> > - base modules can be provided by "base" plugins, and extension modules
> >   by external plugins
> > - plugins can provide parts of modules, entire modules or multiple
> >   modules (like nodes maybe, modifiers, new editors, or extensions to
> >   editors)
> >
> > Dependencies
> > ------------
> > - do we want to have inter-plugin dependencies ? For a slim core
> >   approach this might be necessary, if plugin A provides a module or
> >   part where plugin B 's code depends on
> > - else base modules should be moved / kept in the core, so everyone has
> >   a minimum set of functionality without needing to use plugins
> > - but in general, should plugin code only use Core API (the Hub ?)
> >   would be better than "directly" accessing other plugins code, because
> >   the core might provide the error fallback in case a plugin isnt
> >   present
> >
> > Plugin properties
> > -----------------
> > - should be "hotpluggable", addable, removable during runtime
> > - core needs to take care of disabling all related functionality when
> >   module is unloaded (closing editor, saving for example)
> > - each plugin needs an unique identifier of some kind, and versioning
> >   info
> > - if basis modules are in a plugin, this plugin needs to be flagged as
> >   important or official or so
> > - plugins could be classified by their purpose, like provides Module X,
> >   extends Module Y, replaces Module Z, removes Module W
> >
> >
> > _______________________________________________
> > 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
>