[Bf-committers] Some Ideas for a Blender Plugin System
Gaia Clary
gaia.clary at machinimatrix.org
Tue Nov 3 15:29:08 CET 2015
One of the benefits of a Blender PLugin System (bps) that i can think of is:
The Collada module could be extracted into a separate plugin.
But this can only work well if the bps does not force us to rebuild a
plugin for each blender release. Otherwise maintenance would become a
nightmare, especially because plugins need to be built for multiple
platforms.
cheers,
Gaia
On 03.11.2015 14:14, Dalai Felinto wrote:
> 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
More information about the Bf-committers
mailing list