Hi,
I do not find anything about the "script window" of the Inkscape.
I only know that i need to comple with "--with-python" and/or "--with-perl".
How can i use this? An script hire can access the inkscape features? An internal API like: Inkscape::pathsUnion( $id1, $id2 ); Inkscape::pathsIntersection( $id1, $id2 );
Something like that?
Thank you, Aurium
On Thu, Feb 15, 2007 at 06:19:39PM -0300, Aur?lio A. Heckert wrote:
Hi,
I do not find anything about the "script window" of the Inkscape.
I only know that i need to comple with "--with-python" and/or "--with-perl".
How can i use this? An script hire can access the inkscape features? An internal API like: Inkscape::pathsUnion( $id1, $id2 ); Inkscape::pathsIntersection( $id1, $id2 );
Something like that?
No, this is not implemented yet. It will be in the future though.
Bryce
Talking about that (scripting Inkscape), I am currently looking in details the way Python (which is my primary skilled language) is used in Inkscape.
For now, I am trying to rewrite the inkex.py and all the helper modules so I can write extension scripts the Python way (which I find is not the case today). The code I am writing is dependant on numpy, whih I know can be problematic for Inkscape since it would add an external dependancy. However, I nticesd that at least one extension is actually using numpy (that's what decided me to make numpy a preriquisity of my code).
I'll publish my code as soon as I have something that I can decently make public. My goal is to make path ans objects manipulations as easy as possible, without having to deal with SVG xml node or so in any way. I want to be able to add paths, etc. I other words, to have a nice object API to create effects easily.
However, trying to understand how Python scripting work in Inkscape, I was wondering why the Python interpreter is embedded in the Inkscape executable, according the way Python effects work (simply a Python program that is runned with SVG file in /tmp or so, and with parameters on command line). Why not simply use the Python executable provided by the platform. Any Linux and MacOSX station do have Python installed. In win32, heee, let's ask user to install the Python package if she wants nice scripted effects. So my question is: what is the state of (and roadmap for) using Python as real scripting language for Inkscape (I mean exporting the Inkscape API at Python level), which seem to be the goal of the stuff (if I understand the runme.py file in src/extention/script).
When I have done with my idea on Python effect helpers modules, I may help in implementing this aspect in Inkscape (I don't have that much time free for Inkscape, but I can give 1h/day, during train trip).
David
2007/2/15, Bryce Harrington <bryce@...961...>:
On Thu, Feb 15, 2007 at 06:19:39PM -0300, Aur?lio A. Heckert wrote:
Hi,
I do not find anything about the "script window" of the Inkscape.
I only know that i need to comple with "--with-python" and/or
"--with-perl".
How can i use this? An script hire can access the inkscape features? An internal API like: Inkscape::pathsUnion( $id1, $id2 ); Inkscape::pathsIntersection( $id1, $id2 );
Something like that?
No, this is not implemented yet. It will be in the future though.
Bryce
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
David Douard wrote:
For now, I am trying to rewrite the inkex.py and all the helper modules so I can write extension scripts the Python way (which I find is not the case today).
What is the "Python way"?
The code I am writing is dependant on numpy, whih I know can be problematic for Inkscape since it would add an external dependancy. However, I nticesd that at least one extension is actually using numpy (that's what decided me to make numpy a preriquisity of my code).
numpy shouldn't be a problem.
I'll publish my code as soon as I have something that I can decently make public. My goal is to make path ans objects manipulations as easy as possible, without having to deal with SVG xml node or so in any way. I want to be able to add paths, etc. I other words, to have a nice object API to create effects easily.
That would be great. One of the original goal was to combine inkex.py with SVG-Utils from programmer-art.org. But I was never able to get the authors to respond to my comments and questions.
http://web.archive.org/web/20041212142734/programmer-art.org/svg-utils
(I had to use opera to open that link because the xml is invalid.)
And you will notice that the project is completely absent from their new site.
It was GPL, you may be interested in using it as a starting point.
One thing I would suggest: don't completely hide the low level XML. Having access is just too too useful. The SVG spec is very large. Inkscape still hasn't implemented it all. If you seek to hide XML from the user you'll have to redo all the work that Inkscape has done and more.
Another project that may help you as you seek to do amazing things is lib2geom. ( http://lib2geom.sourceforge.net/ ) A few of the Inkscape developers have started this project to develop a mathematical engine to back Inkscape. Python bindings have been started but are quite unfinished. You might just want to lend a hand to this project and make your work easier.
However, trying to understand how Python scripting work in Inkscape, I was wondering why the Python interpreter is embedded in the Inkscape executable, according the way Python effects work (simply a Python program that is runned with SVG file in /tmp or so, and with parameters on command line). Why not simply use the Python executable provided by the platform. Any Linux and MacOSX station do have Python installed. In win32, heee, let's ask user to install the Python package if she wants nice scripted effects.
Um, that is how we do it. Everything Inkscape does uses the platform's python interpreter. Well, almost. On win32 we ship python with Inkscape so that the users can use effects right out of the box. You can find more information about extensions on the wiki.
http://wiki.inkscape.org/wiki/index.php/Category:Extensions
If you plan to fix the problems with inkex.py, it might help to write a few extensions with it.
The embedded interpreter that you see is meant to be used for the day when we expose Inkscape's internals to scripting. As the presence of the interpreter would suggest, the work has started. But it isn't finished yet. You may also be interested in helping with this work.
Aaron Spike
2007/2/16, Aaron Spike <aaron@...749...>:
David Douard wrote:
For now, I am trying to rewrite the inkex.py and all the helper modules so I can write extension scripts the Python way (which I find is not the case today).
What is the "Python way"?
I hope I'll have something to show soon, which will be something *I* find more pythonic ;-)
The code I am writing is dependant on numpy, whih I know
can be problematic for Inkscape since it would add an external dependancy. However, I nticesd that at least one extension is actually using numpy (that's what decided me to make numpy a preriquisity of my code).
numpy shouldn't be a problem.
Cool! This really is a good news to me. Many stuffs (related to bezier and geometrics) should really be simpler to write now.
I'll publish my code as soon as I have something that I can decently
make public. My goal is to make path ans objects manipulations as easy as possible, without having to deal with SVG xml node or so in any way. I want to be able to add paths, etc. I other words, to have a nice object API to create effects easily.
That would be great. One of the original goal was to combine inkex.py with SVG-Utils from programmer-art.org. But I was never able to get the authors to respond to my comments and questions.
http://web.archive.org/web/20041212142734/programmer-art.org/svg-utils
(I had to use opera to open that link because the xml is invalid.)
And you will notice that the project is completely absent from their new site.
It was GPL, you may be interested in using it as a starting point.
I'll have a look, thanks.
One thing I would suggest: don't completely hide the low level XML.
Having access is just too too useful. The SVG spec is very large. Inkscape still hasn't implemented it all. If you seek to hide XML from the user you'll have to redo all the work that Inkscape has done and more.
Sure. My idea is not to hide XML, just to let user (at least the one who write a Python extension script) have a "hight" level API to do simple things easily. If digging the XML code is the simplest solution for some effect, I'll try to make my code friendly with this too.
Another project that may help you as you seek to do amazing things is
lib2geom. ( http://lib2geom.sourceforge.net/ ) A few of the Inkscape developers have started this project to develop a mathematical engine to back Inkscape. Python bindings have been started but are quite unfinished. You might just want to lend a hand to this project and make your work easier.
Sure. I've not yet took time to investigate this lib, but this is in my TODO's.
However, trying to understand how Python scripting work in Inkscape, I
was wondering why the Python interpreter is embedded in the Inkscape executable, according the way Python effects work (simply a Python program that is runned with SVG file in /tmp or so, and with parameters on command line). Why not simply use the Python executable provided by the platform. Any Linux and MacOSX station do have Python installed. In win32, heee, let's ask user to install the Python package if she wants nice scripted effects.
Um, that is how we do it. Everything Inkscape does uses the platform's python interpreter. Well, almost. On win32 we ship python with Inkscape so that the users can use effects right out of the box. You can find more information about extensions on the wiki.
Ok, I think I understand better now. My first idea is to work on inkex.py stuffs so I have a nice "toolkit" to easily write effect scripts. Then I'll have a look at the embedded Python to be able to really extend Inkscape with Python. But I need to understand better the Inkscape code first.
BTW, I also wrote a very little patch that make Inkscape add a "--nodes" option to an effect command line when in "node sculpiting" mode, with a list of selected nodes in a path. Should I send it here ? For now, I do not have an effect that use it, but as soon as I have a beginning of working inkex.pyworking the way I want, I'll write a "bevel" effect (that bevel angles of a path at selected nodes, with a given radius. In fact, this feature is the reason of my investigation in the code and the Python effect framework in Inkscape).
If you plan to fix the problems with inkex.py, it might help to write a
few extensions with it.
The embedded interpreter that you see is meant to be used for the day when we expose Inkscape's internals to scripting. As the presence of the interpreter would suggest, the work has started. But it isn't finished yet. You may also be interested in helping with this work.
Aaron Spike
Thanks for all, David
On Mon, 2007-02-19 at 10:03 +0100, David Douard wrote:
BTW, I also wrote a very little patch that make Inkscape add a "--nodes" option to an effect command line when in "node sculpiting" mode, with a list of selected nodes in a path. Should I send it here ? For now, I do not have an effect that use it, but as soon as I have a beginning of working inkex.py working the way I want, I'll write a "bevel" effect (that bevel angles of a path at selected nodes, with a given radius. In fact, this feature is the reason of my investigation in the code and the Python effect framework in Inkscape).
Cool. Do you have the patch posted somewhere?
--Ted
participants (5)
-
Aaron Spike -
Aurélio A. Heckert -
Bryce Harrington -
David Douard -
Ted Gould