![](https://secure.gravatar.com/avatar/d6adbfa9bbedfe84f3b156e0879f0aa6.jpg?s=120&d=mm&r=g)
On Fri, 17 Mar 2006 14:12:14 -0400 "bulia byak" <buliabyak@...155...> wrote:
On 2/27/06, Terry Hancock <hancock@...1624...> wrote:
However, the whole point of it being a plug-in (rather than just filtering the SVG file) is so that I can make use of program state information -- specifically what is selected (and "last selected", "first-selected", etc), what the current style settings are, etc.
AFAIK, the ids of selected objects are being passed to your script as command line params. I don't know what other capabilities exist beyond this, but I think it will be easy to add them if you really need them.
Thanks for the information. I've been looking into the example scripts since I posted the above. They do apparently make use of the selection, so I should be able to figure it out (even if it should turn out this is not the way it works).
OTOH, I still haven't gotten the examples to work. I expect I'm missing something in the preferences file, since I don't have an extensions menu yet. I'm hoping that will become obvious by the time I tackle it again. :-)
However, I've realized there is one more obstacle I'm probably going to run into:
I'm writing an application which is not just a filter, but should run alongside Inkscape, I want to be able to pass information to and from it. I think I can solve the interprocess communication problem in my own software (not trivial since I've never tried it, but there are facilities for it in Python).
Ideally I would be able to have a signal from my app trigger an export script in Inkscape (i.e. it would need an automation API of some kind). I'm not sure how to make that work. Maybe Mozilla might be a good model for that (you can automate an existing mozilla instance by running commands such as "mozilla openURL(http://localhost) new-window" and so on -- this doesn't start a new mozilla process, but just sends a signal to the currently open one). I have no idea how hard that would be for you to do.
In the meantime, I have a work-around in mind -- I can create FIFO queues for import and export of data, so that the program need only read the last item off of the queue, and export next item to the queue. Then the actual plugins in Inkscape only have to read and write to the queues. It'd be possible for the user to trigger the import and export from Inkscape manually:
VectorEditor Plugins Application
/ AM_Export_to_Queue --->\ "import" Inkscape > AutoManga \ AM_ImportfromQueue <---/ "export"
But of course, that has some awkwardness for the user, so it'd be kind of cool if there was a way to trigger the queue scripts from outside of Inkscape.
I was originally trying to write this utility for Skencil, which is mostly written in Python and has a number of hooks for this kind of thing (Skencil exposes a lot of callbacks to plugins/scripts). OTOH, serializing the data is easier with Inkscape, since everything is stored as SVG anyway (the most awkward thing is that all drawing objects in Skencil are 'extension objects', so they won't pickle!). I also just like the idea of using SVG representations in my own data files. Getting that in and out of Skencil will be more of a challenge. It seems likely that I'll wind up trying to write a program that works with either drawing program.
Anyway, I'm still trying to get my head around how the program should interact with Inkscape.
Thanks again for the response.
Cheers, Terry