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

Dalai Felinto dfelinto at gmail.com
Tue Nov 3 14:14:32 CET 2015


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


More information about the Bf-committers mailing list