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...