[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