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