Hi Krzysztof,
thank you for your quick response.
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.
Great. We should be able to deal 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.
Understood. We were thinking that it might have been a good chance for you to add some instrumentation support (collecting statistics about feature use of the program) with the ability to dynamically unload the feature if the user opts-out. However, this is was only an idea and can - of course - be implemented in another fashion.
Anyway, we'll be looking into providing a patch with the corresponding configure options and get in touch again when we're ready.
So long and thanks for all the fish,
Sebastian
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: Mittwoch, 10. Juni 2015 02:46 To: Sebastian Faubel Cc: inkscape-devel; Athanasios Velios Subject: Re: [Inkscape-devel] Would you accept patches for a C++ Plugin implementation?
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