Sorry I don't know enough about the subject to formulate more proper questions. I'm interested in learning more about the python scripting support. I realize it is a ways down on the roadmap still, but occasionally I hear a bit about it. Is there anything in CVS that I can try or anything I can read to learn more and watch it develop?
Aaron Spike
On Mon, 2005-03-28 at 21:09 -0600, fretfind@...540... wrote
Sorry I don't know enough about the subject to formulate more proper questions. I'm interested in learning more about the python scripting support. I realize it is a ways down on the roadmap still, but occasionally I hear a bit about it. Is there anything in CVS that I can try or anything I can read to learn more and watch it develop?
Well, there are two answers to your question:
1) If you're looking to execute Python scripts in Inkscape you can load the Python interpreter using a flag to your ./configure script. Basically you can execute any Python you'd like, but that really isn't that useful as it is waiting on an API to support the functionality in Inkscape. Ishmal is working on implementing DOM for Inkscape, which will turn into that API.
2) If you'd like to have an external script called by Inkscape and integrated in, that will work today. The external script will have to be able to take in SVG as STDIN or STDOUT, I'm sure that there is a Python library to work with SVG. Then, you can do what ever you want with it from there. If you're interested in working with this method, I can provide more information based on what your goals are.
--Ted
Ted Gould wrote:
- If you're looking to execute Python scripts in Inkscape you can load
the Python interpreter using a flag to your ./configure script. Basically you can execute any Python you'd like, but that really isn't that useful as it is waiting on an API to support the functionality in Inkscape. Ishmal is working on implementing DOM for Inkscape, which will turn into that API.
This is what I am anxiously waiting for. I've tried to enable the Python interpreter with configure flags, but I just don't think I'm doing it correctly. When ever I include the flag configure reports the status "no" instead of "skipped". But if there is no comunication between Inkscape and the embedded interpreter, that does make it significantly less useful at the moment. I think I've seen some of Ishmal's code in CVS. Can't wait till he has something working.
- If you'd like to have an external script called by Inkscape and
integrated in, that will work today. The external script will have to be able to take in SVG as STDIN or STDOUT, I'm sure that there is a Python library to work with SVG. Then, you can do what ever you want with it from there.
I suppose I should try this out. I've done a small amount of reading about this in the past but I still have a host of questions. Will this work without writing code in C++? Do the filter type extensions only pump out the full SVG file or is it possible to send and replace just selected objects?
If you're interested in working with this method, I can provide more information based on what your goals are.
I have no goals other than fun and learning. I'd like to help out but I'm not quite ready to dive into C++ (getting there slowly). I've just now gained enough experience to be able to compile CVS daily for my own use. I think I see many things in the RFE tracker that probably aren't useful enough to the broad Inkscape audience for someone to invest a bunch of time coding or to clutter the UI. Many of those RFE could be addressed quite easily by someone like myself with marginal coding skills and a proper extension architecture. I'd love to learn more. Please point me in the right direction.
Thanks, Aaron Spike
fretfind@...540... wrote:
Ted Gould wrote:
- If you're looking to execute Python scripts in Inkscape you can load
the Python interpreter using a flag to your ./configure script.
This is what I am anxiously waiting for. I've tried to enable the Python interpreter with configure flags, but I just don't think I'm doing it correctly. When ever I include the flag configure reports the status "no" instead of "skipped".
More specifically, here are the configure commands I've used and the corresponding output:
# CXX='ccache g++' ./configure <snip> Use Python extensions: skipped Use Perl extensions: skipped
# CXX='ccache g++' ./configure --with-python=yes <snip> Use Python extensions: no Use Perl extensions: skipped
What am I doing wrong?
And I have a second question. Last night I added the following to my ~/.inkscape/preferences.xml file:
<group show-effects-menu="1" id="extensions" />
I can now see the effects menu, but the effects (for instance "DropShadow") don't seem to affect anything. What is the proceedure for using these effects?
Aaron Spike
On Wed, 2005-03-30 at 18:13 -0600, fretfind@...540... wrote:
# CXX='ccache g++' ./configure --with-python=yes
<snip> Use Python extensions: no Use Perl extensions: skipped
What am I doing wrong?
I'm not sure on this one, I'm guessing it is because you're missing some of the python development libraries. I know that I had to find something rather obscure -- but I don't remember what it was. Anyone?
And I have a second question. Last night I added the following to my ~/.inkscape/preferences.xml file:
<group show-effects-menu="1" id="extensions" />
I can now see the effects menu, but the effects (for instance "DropShadow") don't seem to affect anything. What is the proceedure for using these effects?
Well, probably your issue with that one is that you have to have the object selected that you want to put the drop shadow on. So, if there is a square in the middle of the screen, you can select it, hit drop shadow, and you'll have one. The reason that they're turned off by default is that they're not user friendly yet :) Also, the "Blur Edges" effect requires that the selected object be a path (Object to Path first).
--Ted
Ted Gould wrote:
On Wed, 2005-03-30 at 18:13 -0600, fretfind@...540... wrote:
# CXX='ccache g++' ./configure --with-python=yes What am I doing wrong?
I'm not sure on this one, I'm guessing it is because you're missing some of the python development libraries. I know that I had to find something rather obscure -- but I don't remember what it was. Anyone?
I'm feeling really stupid right now. I don't think there is anything obscure required. Just those painfully obvious *-dev packages. I can't believe they weren't installed already.
I can now see the effects menu, but the effects (for instance "DropShadow") don't seem to affect anything. What is the proceedure for using these effects?
Well, probably your issue with that one is that you have to have the object selected that you want to put the drop shadow on. So, if there is a square in the middle of the screen, you can select it, hit drop shadow, and you'll have one. The reason that they're turned off by default is that they're not user friendly yet :) Also, the "Blur Edges" effect requires that the selected object be a path (Object to Path first).
And that makes me wonder if I'm missing something painfully obvious here too. To-Path and Selected are what I had already tried. Now I'm out of ideas, other than possibly I didn't enable something I should have. Now that the effects menu is turned on in the preferences.xml file, do I need to change any defines in the code? If it helps, I'm running debian sid, installing inkscape into /usr/local and I have the sid package installed as well.
Aaron Spike
On Thu, Mar 31, 2005 at 06:55:45AM -0600, fretfind@...540... wrote: [...SNIP...]
And that makes me wonder if I'm missing something painfully obvious here too. To-Path and Selected are what I had already tried. Now I'm out of ideas, other than possibly I didn't enable something I should have. Now that the effects menu is turned on in the preferences.xml file, do I need to change any defines in the code? If it helps, I'm running debian sid, installing inkscape into /usr/local and I have the sid package installed as well.
Hi,
probably that's to simple, but the painfully obvious I do sometimes wrong if I install s.th. to /usr/local while there is the real package installed ist that I type inkscape without thinking and get the original one. Are you sure you use /usr/local/bin/inkscape? "which inkscape" tells you more.
With best wishes,
Wolfi
Aaron Spike
This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Wolfram Quester wrote:
probably that's to simple, but the painfully obvious I do sometimes wrong if I install s.th. to /usr/local while there is the real package installed ist that I type inkscape without thinking and get the original one. Are you sure you use /usr/local/bin/inkscape? "which inkscape" tells you more.
I'll check that again when I get home. I tried both versions this morning and I think I can tell the difference just by looking because the icon sizes are so dramatically different. And now that I think of it, because it failed with both versions I am probably missing a dependency of the scripts. Or as Bulia just mentioned in a different thread perhaps I have the wrong version of imagemagick etc. I will check again and read the *.inx files a little more closely. For now I'm still accepting suggestions.
Thanks,
Aaron Spike
fretfind@...540... wrote:
I am probably missing a dependency of the scripts.
That appears to be my problem. After "apt-get install libxml-xql-perl" the Dropshadow effect now works. The other effects (grid, blur edges, etc.) still seem to have no effect. And since they are plugins and not scripts, I really have no idea how to debug them. Any ideas?
Now that I have a working script to look at I should be able to try my hand at writing some. Thanks for helping me stumble through this. Hopefully I'll be able to help next time the question comes up.
Aaron Spike
On Thu, 31 Mar 2005 fretfind@...540... wrote:
That appears to be my problem. After "apt-get install libxml-xql-perl" the Dropshadow effect now works. The other effects (grid, blur edges, etc.) still seem to have no effect. And since they are plugins and not scripts, I really have no idea how to debug them. Any ideas?
On the console it will tell if they linked in okay... if they didn't then they wouldn't work. To be entirely honest, they are kinda fragile right now. I'm planning on making them internal extensions -- I think I was a bit over zealous with the plugin stuff.
Some things that might be wrong, is your binary stripped? If there is no internal symbols they won't connect in. Also, they really need to be the same version as the binary. If you're not doing a "make install" everytime they can get out of sync in unhappy ways.
--Ted
ted@...11... wrote:
On Thu, 31 Mar 2005 fretfind@...540... wrote:
That appears to be my problem. After "apt-get install libxml-xql-perl" the Dropshadow effect now works. The other effects (grid, blur edges, etc.) still seem to have no effect. And since they are plugins and not scripts, I really have no idea how to debug them. Any ideas?
On the console it will tell if they linked in okay... if they didn't then they wouldn't work. To be entirely honest, they are kinda fragile right now. I'm planning on making them internal extensions -- I think I was a bit over zealous with the plugin stuff.
Some things that might be wrong, is your binary stripped? If there is no internal symbols they won't connect in. Also, they really need to be the same version as the binary. If you're not doing a "make install" everytime they can get out of sync in unhappy ways.
To show my ignorance... I don't know how to strip a binary, so I'll assume it isn't stripped. And I do do "make install" after each compile. Unless figuring out why the plugins don't work for me can benefit Inkscape's development in some way, I think I'll just let this be for now and concentrate on learning about the posibilities of scripting effects.
Thanks very much for your help so far. Aaron Spike
I have started to post my experience with learning about writing inkscape extensions in python, in case there are others who are as clueless as I am and could benefit even from bad examples.
http://www.ekips.org/comp/inkscape/extending.php
I will continue adding extension examples as I write them. Those of you who are in the know, please take it easy on me. I'm a complete neophite.
Aaron Spike
On Sat, 2 Apr 2005 fretfind@...540... wrote:
I have started to post my experience with learning about writing inkscape extensions in python, in case there are others who are as clueless as I am and could benefit even from bad examples.
http://www.ekips.org/comp/inkscape/extending.php
I will continue adding extension examples as I write them. Those of you who are in the know, please take it easy on me. I'm a complete neophite.
This is really nice. Aaron, one thing that we'd talked about in the past is starting to move twoards having a seperate package of scripts, to remove some dependencies from the base Inkscape package. So, you'd have "inkscape.rpm" and "inkscape-scripts-python.rpm" that you'd install (if you wanted).
As someone who is starting to write more scripts, do you have thoughts on this? Would you perhaps want to start such a package? Do any of the packagers out there have any thoughts?
--Ted
Hi, all...
fretfind@...540... wrote:
More specifically, here are the configure commands I've used and the corresponding output:
# CXX='ccache g++' ./configure
<snip> Use Python extensions: skipped Use Perl extensions: skipped
# CXX='ccache g++' ./configure --with-python=yes
<snip> Use Python extensions: no Use Perl extensions: skipped
What am I doing wrong?
The with-perl and with-python sections of configure.ac have always been clunky and could use some improvement. Even when you use --with-perl and --with-python, they need to be found by the script. Unlike a lot of other libs that we use, those tools do not use libtool or pkg-config to report their CFLAGS and LDFLAGS information. Both Python and Perl have their own mechanism to report their embedding information. In both cases I think they are a bit clumsy also. Someone might want to look at that part of the script to see if they have any ideas.
However, all you will get from the scripts right now are two stubs in both Perl and Python whose only purpose is to prove that scripting is plugged in. There is a hello() that does a "Hello, world." and an about() that shows the About dialog. That's it.
I have spent the past few days working hard to get something working in DOM. Yesterday I got the XPath grammar started, and am now working on a new lexical scanner for it. Once the dom/xpath stuff is plugged in, we should be able to begin scripting Inkscape pieces like this: inkscape::eval("/inkscape/dialogManager/dialog[strokeAndFill].setVisible(true)");
So, Perl and Python should be able to affect Inkscape (and the document, too) when requested. And -finally- the JS lib that we have been carrying for so long will be usable, and will always be available.
However, in the meantime, there should be nothing preventing anyone from scripting anything -outside- of Inkscape with Perl or Python.
Bob
On Tue, 2005-03-29 at 21:16 -0600, fretfind@...540... wrote:
- If you'd like to have an external script called by Inkscape and
integrated in, that will work today. The external script will have to be able to take in SVG as STDIN or STDOUT, I'm sure that there is a Python library to work with SVG. Then, you can do what ever you want with it from there.
I suppose I should try this out. I've done a small amount of reading about this in the past but I still have a host of questions. Will this work without writing code in C++? Do the filter type extensions only pump out the full SVG file or is it possible to send and replace just selected objects?
Effect always deal with the whole SVG file, but they are given the list of selected objects as parameters on the command line. The reason the whole file is given is so that things like patterns and gradients can be created/used more easily. Also, if you wanted to do some special Z-ordering or something like that, you'd need the whole document. But, you shouldn't need to write a line of C++, heck you could do it all in Scheme if you so choose.
There is a list of ideas for effects in the Wiki, you're welcome to add more, or implement some in the list.
--Ted
participants (4)
-
unknown＠example.com -
Bob Jamison -
Ted Gould -
Wolfram Quester