I want to add Python support to Inkscape.
From what I read, this should be a script extension. However,
extensions don't seem to show up for me. Are they disabled? Do I need to do something special? Am I looking in the wrong place?
My theory was to implement a svgdom interface (+ maybesome extensions to support inkscape's stars and the like) to the sprepr, so python extensions can be used in any program which supports svgdom. Is this reasonable? Should there be a C++ DOM interface, which I just wrap in Python, or can I just get the sprepr into Python and then use pure Python to wrap it in DOM (easier for me, probably)?
I've been working on XPath and a C++ DOM wrapper for Repr for a few weeks now. I should start to have stuff checked in very soon. I have been using the w3c specs, so that any scripts will be "proper". I have the dom.h interface , a default DOM impl, and I am starting on a Repr impl. I already have an XPath parser working. I need to get the DOM tree in place, to test it.
I think xpath will be pretty cool, if it turns out to work correctly. It will make addressing items in the repr tree from a script very easy, such as xpath.setAttribute("/mydrawing/ball@...510...", "red");
My desire for DOM/xpath comes from the "other side" of the SVG document. I want to bind the Javascript engine to the document, so that <script> nodes in the document can be executable, making the drawing dynamic. The DOM&Xpath stuff should be generic enough, so that scripts from either the Inkscape side, or the document side, should be able to manipulate the document with equal ease.
A couple of the guys have been wanting to use Swig for a generic scripting interface to Inkscape, so that Python, Perl, {your script here} can be easily added to Inkscape. And fortunately, Python is the language bound by default.
So you might try working on that side of the scripting task, and we can build the bridge toward each other and meet in the middle, and get this thing done a lot sooner.
( Heh. "repr wrapper" ) ;)
Bob
David Turner wrote:
I want to add Python support to Inkscape.
From what I read, this should be a script extension. However, extensions don't seem to show up for me. Are they disabled? Do I need to do something special? Am I looking in the wrong place?
My theory was to implement a svgdom interface (+ maybesome extensions to support inkscape's stars and the like) to the sprepr, so python extensions can be used in any program which supports svgdom. Is this reasonable? Should there be a C++ DOM interface, which I just wrap in Python, or can I just get the sprepr into Python and then use pure Python to wrap it in DOM (easier for me, probably)?
I've never used Swig before, but it can't be too hard. Who is working on this?
On Fri, 2004-08-13 at 17:59, Bob Jamison wrote:
A couple of the guys have been wanting to use Swig for a generic scripting interface to Inkscape, so that Python, Perl, {your script here} can be easily added to Inkscape. And fortunately, Python is the language bound by default.
So you might try working on that side of the scripting task, and we can build the bridge toward each other and meet in the middle, and get this thing done a lot sooner.
( Heh. "repr wrapper" ) ;)
Bob
David Turner wrote:
I want to add Python support to Inkscape.
From what I read, this should be a script extension. However, extensions don't seem to show up for me. Are they disabled? Do I need to do something special? Am I looking in the wrong place?
My theory was to implement a svgdom interface (+ maybesome extensions to support inkscape's stars and the like) to the sprepr, so python extensions can be used in any program which supports svgdom. Is this reasonable? Should there be a C++ DOM interface, which I just wrap in Python, or can I just get the sprepr into Python and then use pure Python to wrap it in DOM (easier for me, probably)?
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2004-08-13 at 14:52, David Turner wrote:
I want to add Python support to Inkscape.
Very very cool. This is an oft requested feature.
From what I read, this should be a script extension. However, extensions don't seem to show up for me. Are they disabled? Do I need to do something special? Am I looking in the wrong place?
Well, extensions don't really 'show up' per se. Really, the goal is to make sure the user doesn't realize what is an extension and what isn't. We really want them to be first class functionality in Inkscape. This will make it easier to push more and more functionality to extensions as they become more mature (someday, I promise, really).
Probably the best place to start looking is at this document:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/inkscape/inkscape/doc/exten...
It was written by Bryce, and does a good job of explaining how things are supposed to work -- it is still a work in progress though. Also, some brain storming on APIs that we'd need is in:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/inkscape/inkscape/src/exten...
It is currently in the /src directory so that it can get Doxygen comments added into it. I'm sure that it won't compile and it currently just some rough ideas about functionality we'll need to export to extensions.
I think that you'll probably not want to work with the scripting interface as much as you'll want to write your own implementation. That is basically done by creating a subclass of Inkscape::Extension::Implementation and trying to write as many of the functions as you can. This is basically the interface that Inkscape will call to execute the extension. The interface that the extension calls back to Inkscape is api.h above and DOM bellow.
Implementation class: http://www.inkscape.org/doc/doxygen/html/classInkscape_1_1Extension_1_1Imple...
My theory was to implement a svgdom interface (+ maybesome extensions to support inkscape's stars and the like) to the sprepr, so python extensions can be used in any program which supports svgdom. Is this reasonable? Should there be a C++ DOM interface, which I just wrap in Python, or can I just get the sprepr into Python and then use pure Python to wrap it in DOM (easier for me, probably)?
I think that we're going to have to have a C DOM interface in the end. I think it would probably be easier to implement that as C++ internally, but as far as linking to other interpreters or languages, most like C better. But, ofcourse, first one to implement wins :)
As far as SWIG goes, we've talked about it alot, but I don't think that anyone is currently working on it. If you wanted to implement Python via SWIG that might be cool, as it would allow other languages to play along also.
Okay, I'm starting to babble... Any questions? Ideas?
--Ted
On Mon, 2004-08-16 at 12:19, Ted Gould wrote:
On Fri, 2004-08-13 at 14:52, David Turner wrote:
I want to add Python support to Inkscape.
Very very cool. This is an oft requested feature.
From what I read, this should be a script extension. However, extensions don't seem to show up for me. Are they disabled? Do I need to do something special? Am I looking in the wrong place?
Well, extensions don't really 'show up' per se. Really, the goal is to make sure the user doesn't realize what is an extension and what isn't. We really want them to be first class functionality in Inkscape. This will make it easier to push more and more functionality to extensions as they become more mature (someday, I promise, really).
Probably the best place to start looking is at this document:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/inkscape/inkscape/doc/exten...
I've read that -- I'm just not clear on what's been implemented so far. If there's an example I can cargo-cult^W^H^W work from, I would prefer to do so, but if not, I'll just figure it out from what's there.
On Mon, 2004-08-16 at 12:55, David Turner wrote:
I've read that -- I'm just not clear on what's been implemented so far. If there's an example I can cargo-cult^W^H^W work from, I would prefer to do so, but if not, I'll just figure it out from what's there.
The only complete implementation is the scripting one. /src/extension/implementation/script.cpp. It isn't a language binding though. Think of yourself as an explorer finding new territory! ;)
--Ted
Ted Gould wrote:
I think that we're going to have to have a C DOM interface in the end. I think it would probably be easier to implement that as C++ internally, but as far as linking to other interpreters or languages, most like C better. But, ofcourse, first one to implement wins :)
As far as SWIG goes, we've talked about it alot, but I don't think that anyone is currently working on it. If you wanted to implement Python via SWIG that might be cool, as it would allow other languages to play along also.
I was one working on it, but can't actually code at the moment.
I'm on an ancient RH 8.0 system. Once I get this new HD sitting on the table over there installed and get RH 9.0 installed, I'll be able to catch back up to current code.
However... I've done a lot of analysis.
SWIG allows C++ programs to expose objects and innards to an arbitrary set of language bindings.
SWIG provides a mechanism for *how* to bind C++ to different languages. But not really anything about *what* to bind. Just define what C++ to expose and let SWIG do the heavy lifting of all the language specific binding. Since you get multiple languages for a single config I believe that SWIG gives us some of the most bang for our buck as far as binding goes.
But for the *what* to bind... enter DOM and it's friends (DOM Events, XPath, SVG DOM and some assorted other things like SMIL, XForms, etc).
The W3C has done some decent work here. We can use their IDL's and language bindings to tell us *what* our API should look like.
Here's a quick rundown on the interfaces/bindings that should be considered (add to this list as needed guys):
* DOM http://www.w3.org/TR/DOM-Level-2-Core/ - IDL http://www.w3.org/TR/DOM-Level-2-Core/idl-definitions.html - Java http://www.w3.org/TR/DOM-Level-2-Core/java-binding.html - ECMAScript http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html
* SVG DOM http://www.w3.org/TR/SVG/svgdom.html - IDL http://www.w3.org/TR/SVG/idl.html - Java http://www.w3.org/TR/SVG/java.html - ECMAScript http://www.w3.org/TR/SVG/escript.html
* DOM Level 2 Events http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/ - IDL http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/idl-definitions.ht... - Java http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/java-binding.html - ECMAScript http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/ecma-script-bindin...
* DOM Level 3 Events http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/ - IDL http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/idl-definitions.h... - Java http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/java-binding.html - ECMAScript http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/ecma-script-bindi...
* XPath http://www.w3.org/TR/1999/REC-xpath-19991116
* XForms http://www.w3.org/TR/2003/REC-xforms-20031014
* SMIL 1.0 http://www.w3.org/TR/1998/REC-smil-19980615
* SMIL 2.0 http://www.w3.org/TR/2001/REC-smil20-20010807
One thing I found is that the more you read (including the different language bindings defined... Java & ECMAScript for example) the better you can understand how to leverage things simply and with the most power. Read them all, then code a subset. :-)
Oh, and XPath can be a powerful little scripting language itself.
On Tue, 2004-08-17 at 15:29, Jon A. Cruz wrote:
But for the *what* to bind... enter DOM and it's friends (DOM Events, XPath, SVG DOM and some assorted other things like SMIL, XForms, etc).
The W3C has done some decent work here. We can use their IDL's and language bindings to tell us *what* our API should look like.
While I rather vehemently oppose using DOM for our internal representation (at least at the bottom-most level), I think it is the best choice for our externally visible APIs (at least as the preferred/straightforward option).
DOM's universality aside, one of the reasons for this is that over the next twenty releases or so the internal representation will continue going through some major churn. Having a stable external APIs is a good thing.
Oh, and XPath can be a powerful little scripting language itself.
XPath is a beautiful thing.
-mental
MenTaLguY wrote:
On Tue, 2004-08-17 at 15:29, Jon A. Cruz wrote:
But for the *what* to bind... enter DOM and it's friends (DOM Events, XPath, SVG DOM and some assorted other things like SMIL, XForms, etc).
The W3C has done some decent work here. We can use their IDL's and language bindings to tell us *what* our API should look like.
While I rather vehemently oppose using DOM for our internal representation (at least at the bottom-most level), I think it is the best choice for our externally visible APIs (at least as the preferred/straightforward option).
DOM's universality aside, one of the reasons for this is that over the next twenty releases or so the internal representation will continue going through some major churn. Having a stable external APIs is a good thing.
In the DOM I am making from the w3c idl's, I am going through a lot of extra effort to separate the interface definitions from the implementation. This is a very good example.. If IS's internal representation implementation ever changes from Repr to something else like AST, it would be good to be able to keep a steady API for our scripts & stuff.
I am almost done with a "default" DOM implementation, now I need to start on the repr-oriented implementation.
Bob
On Thu, 2004-08-19 at 08:00, Bob Jamison wrote:
I am almost done with a "default" DOM implementation, now I need to start on the repr-oriented implementation.
One thing to be aware of is that DOM does namespaces a little differently than we do -- it expects a ( qname, namespace_uri ) tuple to be stored for each element/attribute name.
This actually has no relationship to the xmlns declarations currently in effect -- so you can glom arbitrary prefix/namespace combinations into the tree, and if you serialize it later it's up to the serialization implementation to work out a sane set of prefixes to use.
By contrast, the model we use in SPRepr currently is to store only qnames, and force a global prefix<->namespace mapping onto everything -- effectively we store expanded names, using prefixes as a shorthand.
I plan to keep this system in AST (with a few refinements so there aren't any nasty ambiguous cases), so be aware that to make DOM behave as expected you will need to store a "DOM prefix" somewhere for every element/attribute name, which would be the prefix that was set via the DOM API. The namespace URI and local name, however, can be derived from the Repr/AST "expanded" name.
-mental
participants (5)
-
Bob Jamison -
David Turner -
Jon A. Cruz -
MenTaLguY -
Ted Gould