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

Hi Jon,

sounds interesting. Maybe you also want to take inspiration for the plugin API design from commercial applications such as Adobe Illustrator. What works for them could also be beneficial for Inkscape. Anyway, if there are concrete specs for the API or if I can participate in some way - just let me know.

All the best,

Sebastian

2015-06-12 7:45 GMT+02:00 Jon A. Cruz <jon@...18...>:

On Tue, Jun 9, 2015, at 07:59 AM, Sebastian Faubel wrote:

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.

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?

Hi,

There have been a few approaches for a plugins v2 API over the years, but we do want to get something in place that can hold up long term. I believe that Krzysztof covered fairly well some of the problems with just exposing internals at the moment.

The gist of the 2.0 API we had been working towards started with exposing the SVG as a live DOM. In fact we had a fair bit of code implemented at one point. With newer advances on the main codebase, however, it was decided that the DOM code had become stale and should be removed in favor of implementing more directly on the newer C++ code.

Also... the current set of plugin support does support C++ ones, however it uses a very simplistic API.

If you are interested in actually working on implementation code (which sounds like the case here), we should update some of the general architecture plans that had been worked out with input from several different projects and look for overlap in the aspects that you have need to use.

-- Jon A. Cruz jon@...18...