On 2010-10-01 23:41, Dan Eicher wrote: > On Fri, Oct 1, 2010 at 3:19 AM, Peter Schlaile <pe...@schlaile.de> wrote: > >> Hi, >> >>> I have libplugin (http://libplugin.sourceforge.net/intro.html) working >> in >>> blender. Well, extensions and join-points at least, still haven't ported >>> over the (semi-)current plugin systems to use it. When I say 'working' I >>> mean on linux building with cmake BTW, probably be a chore to get windows >>> going since it brings a couple extra libs into blenderdom. >> >> in fact, it doesn't look like the way, a plugin system for blender should >> work IMHO. We are not aiming at *replacing* core functionality, but >> providing a clean way, to add certain types of filters / effect tracks >> etc. >> >> It's really just a wrapper around the .so/.dll symbol fetching functions > plus some 'object abstraction' at its core,
Yes, but it's quite different from what we're trying to do here. Libplugin assumes that the application has extension points where plugins can be added. Each extension point can have, if I understand the docs and illustrations right, *one* plugin; since the function pointer that is the extension point can only point to one place. We need for each extension point to have more than one plugin, and to be able to identify and select between them at runtime. Libplugin has more in common with aspects than plugins. Sorry if I got it wrong. /LS _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
