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