I'm interested in writing a Python companion tool that would be able to work as a plugin or script with Inkscape. So far, I have found the following resources:
http://wiki.inkscape.org/wiki/index.php/ScriptingHOWTO http://www.ekips.org/comp/inkscape/extending.php#ignorance
I feel pretty confident that I can parse and manipulate SVG, so this goes a long way towards the right solution. In fact I see this as one of the better aspects of working with Inkscape (I hope to also make this tool work with Skencil and possibly Synfig (if I can ever get it working), but the data is represented differently in each. I can easily imagine using SVG as a neutral format, though, and that would seem to favor Inkscape).
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.
Typical use would be to work with a drawing, select a portion of it, and apply my script to that portion. Clearly my script will need to know which part of the document to modify.
So -- can anybody tell me if this is currently possible?
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.
Aaron, can you answer this question in more detail?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak 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.
The ids are passed as command line parameters and they are passed in order, so you can determine what is selected first and what is selected last.
As far as adding capabilities, I mostly oppose this because I believe that the real power of this mechanism is in its Spartan simplicity. I'd rather see effort put toward the internal effects mechanism where things will be much more closely coupled and much more convenient. That said, I would never stand in the way of anyone armed with a patch. ;-)
Aaron Spike
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
On Friday, March 17, 2006, at 10:05 PM, Terry Hancock wrote:
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).
Try getting onto the Inkscape Jabber channel in a few days. There might be some other way to approach things you could take. Otherwise it's starting to sound like what we might want to refactor the extensions mechanism to do, and there are pieces almost ready to start working that out.
On Sat, 18 Mar 2006 00:55:26 +0100 Jon Cruz <jon@...204...> wrote:
On Friday, March 17, 2006, at 10:05 PM, Terry Hancock wrote:
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).
Try getting onto the Inkscape Jabber channel in a few days. There might be some other way to approach things you could take. Otherwise it's starting to sound like what we might want to refactor the extensions mechanism to do, and there are pieces almost ready to start working that out.
Hmm. "Extensions module" sounds promising. Is this something that will have multiple-language bindings (or at least Python for my part)? I haven't programmed anything in C in years (and realistically, it's probably going to stay that way).
On Saturday, March 18, 2006, at 03:10 AM, Terry Hancock wrote:
Hmm. "Extensions module" sounds promising. Is this something that will have multiple-language bindings (or at least Python for my part)? I haven't programmed anything in C in years (and realistically, it's probably going to stay that way).
The current plan is to get things to the point where we expose a live DOM tree. Then we can use SWIG to bind various languages to it, including Python.
Bob's already got a lot of the stand-alone DOM work done, now I have to take things up and see that it gets integrated well. I wouldn't expect it to be in for our next release, but RSN after that. :-)
On Fri, 2006-03-17 at 15:05 -0600, Terry Hancock wrote:
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).
Well, to be entirely honest, the effects system really isn't designed for this. Probably one thing that you'll run into is that the execution of the script is a blocking call, so there is no way to do constant interaction between Inkscape and the script.
One thing that you might consider is that we'll probably implement something like "Live Effects" here pretty shortly. I've been thinking about it, and Aaron made a branch for it, so it's definitely on the table (though, we haven't coordinated). What that would allow is the script to be run every time one of the base objects changes. So, if you can think in the interpolate case, it would redo the interpolation each time one of the base paths changes. This might be useful for you. Also, remember that Inkscape will leave other XML namespaces in the document. So you can add additional properties in the SVG by adding an additional namespace for you effect.
In the short term, someone would have to re-execute the effect with changes, but that is made easier by there being a hot key for "Last Effect".
As far as allowing for the events and interaction, that will come. It's currently on hold as the DOM is not finished yet. But, it is critical for having a "first class extension system" which is listed as one of the project's goals.
--Ted
On Sat, 18 Mar 2006 10:55:47 -0800 Ted Gould <ted@...10...> wrote:
On Fri, 2006-03-17 at 15:05 -0600, Terry Hancock wrote:
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).
Well, to be entirely honest, the effects system really isn't designed for this. Probably one thing that you'll run into is that the execution of the script is a blocking call, so there is no way to do constant interaction between Inkscape and the script.
Yeah, I figured that would be the case. I was expecting that I would have to spawn an independent process from my script, then return. This wouldn't be any harder than interprocess stuff usually is (but I gather that's hard enough -- like I say, I haven't actually tried it. I suspect the bear is getting it to work properly on all platforms).
Still, I can do that if I need to.
One thing that you might consider is that we'll probably implement something like "Live Effects" here pretty shortly. I've been thinking about it, and Aaron made a branch for it, so it's definitely on the table (though, we haven't coordinated). What that would allow is the script to be run every time one of the base objects changes. So, if you can think in the interpolate case, it would redo the interpolation each time one of the base paths changes. This might be useful for you.
It sounds interesting, though not for this project.
My package will have the following kinds of interactions with Inkscape (or Skencil -- I've thought of trying to make it work with both):
1) Symbol library -- especially "pre-rigged" components into the Inkscape SVG
2) Displacing and altering the drawing according to "sliders", AKA "digital puppetry".
3) Procedural effects drawing multiple objects into the Inkscape drawing following a "control object". This by itself is possible with the filter interface.
4) Importing drawing elements into symbol and shape libraries, to be used by the procedural effects, and for editing rigging.
Also, remember that Inkscape will leave other XML namespaces in the document. So you can add additional properties in the SVG by adding an additional namespace for you effect.
Well, I guessed it might, then I tested it. I'm glad to know it's a documented feature. ;-)
In the short term, someone would have to re-execute the effect with changes, but that is made easier by there being a hot key for "Last Effect".
Well, it's not a matter of attaching an updatable change (as it happens I *can* think of an application for that, but it's on a different project).
My app will be managing a lot of drawings and parts of drawings, and needs to exchange data with Inkscape.
Basically, I want to use Inkscape as the editor for components to be used as well as the target for using those elements to apply effects back into the drawing. So it's not so much a matter of needing updates to individual objects as of wanting to maintain a persistent application managing objects.
As far as allowing for the events and interaction, that will come. It's currently on hold as the DOM is not finished yet. But, it is critical for having a "first class extension system" which is listed as one of the project's goals.
Well, that's probably what I'll want to use eventually. I can probably make the FIFO/interprocess approach work in the meantime. It's kludgy, but I think it'll work well enough for the job at hand.
Anyway, I appreciate the responses. I'll be following the progress on the DOM/"first class extension system" with interest.
On my own project, I've finished recreating the UI layer in Glade/PyGTK for one part of it (the "digital screentones" tool), and have about 75% of the object-model code (the missing 25% being the serialization for the shape library -- I got stumped by problems in Skencil, and stopped work on it. Inkscape reduces this decision to "Hey, just use XML", which is the reason I'm now working with it.), and a rough outline of how the procedural code will work (I have absolutely no fear of the procedural code -- I can write that in my sleep. It's having everything else running so I can see the result that takes time).
Cheers, Terry
participants (5)
-
Aaron Spike
-
bulia byak
-
Jon Cruz
-
Ted Gould
-
Terry Hancock