2015-06-09 16:59 GMT+02:00 Sebastian Faubel <sebastian@...3248...>:
Hello everybody,
I'm working as a contractor for the University of the Arts, London. Currently, we're developing a Semantic Desktop to capture data about the creative process which is currently based on Linux, Inkscape and Zeitgeist [0].
In order to realize pushing events from Inkscape into Zeitgeist, we have currently created a fork and implemented the functionality as an internal plugin. This works well, but requires us to maintain a patched version of Inkscape. When i was starting with the implementation I stumbled across a site mentioned in your Wiki [1], which says:
"Plug-in" - a loadable module with a message handler routine that receives messages and that operates on the Inkscape API functions directly.
I think currently the best way to proceed is for you to simply submit this internal plugin for inclusion upstream in Inkscape. If it has additional dependencies, add some configure code so that the plugin is compiled only if they are present.
When I was digging in the source code I found some commented-out parts of the software [2] which contained code for those plugins, which seem to be native C++ plugins. It seems to me, that support for native plugins was prepared but never fully implemented.
As we'd like to contribute something to your project we'd be looking into developing the missing plugin support. So we're asking: Would you be accepting patches for the C++ plugin support? And may be you know why it was never implemented? Are there any fundamental issues with this?
Plugin support only makes sense if there is a reasonably stable, well designed set of functions inside Inkscape that the plugins can call - the plugin API. Compared to achieving that, adding the ability to load SOs / DLLs from some directory is fairly trivial. Currently the plugin API does not exist - the internal API is not stable, and probably won't be any time soon. We had several changes recently, and some crucial parts are still missing, such as a selection object not tied to the UI selection.
I think that adding a plugin loader right now may be counterproductive - people will use it and then find out that their plugins break in the next version. Pushing your code upstream may be a better solution.
Regards, Krzysztof