On Sat, 18 Mar 2006 10:55:47 -0800
Ted Gould <ted@...> 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
> 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
> 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
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).
Terry Hancock (hancock@...)
Anansi Spaceworks http://www.AnansiSpaceworks.com