Bug Report and new Extension
Hi-
I finally signed up on Launchpad, so I hope I did this correctly...
I had written an extension to re-stack selected items (left to right, top to bottom, or vice versa) using a specified base point on each object. I posted about this on the inkscape users list.
Recently I converted it to work with lxml.etree (Thanks Ted, Aaron, and Radek).
It was really slow however, as it would call new instances of inkscape to get the location of the objects. Kurt pointed out this bug report/patch https://bugs.launchpad.net/inkscape/+bug/174701 that provides a --querry-all command lie option, so I converted it.
It now works, and it quite fast. In doing this, I found a bug in the live preview and optiongroups which I reported as a new bug: https://bugs.launchpad.net/inkscape/+bug/181799
I have attached the extension to that bug report, as I could find no other extension using the optionsgroup parameter type (other than the developer example that doesn't effect the drawing).
My questions are:
1) Is it worth getting my extension added to the distribution? (This thread has an example of what it does http://inkscape-forum.andreas-s.net/topic/133367#594472 but using the old code) 2) If so, can someone check my python? I have never used python before this and it was a significant effort in trial and error (I am not sure if the csv to list conversion is really necessary, but couldn't get it to work otherwise) 3) Also if so, should I "submit it" as another bug report in launchpad (or is there a different way to offer up an extension to the project)?
Thanks,
-Rob A>
On Thu, Jan 10, 2008 at 11:08:17AM -0500, Rob Antonishen wrote:
- Is it worth getting my extension added to the distribution? (This
thread has an example of what it does http://inkscape-forum.andreas-s.net/topic/133367#594472 but using the old code)
It's too late to add it for 0.46, but you might hold onto it until after the release is branched.
The performance issue and the need of calling a second instance of Inkscape suggests it might be better implemented as Inkscape C++ code than as an extension, but maybe one of the other extension writers knows a trick.
- If so, can someone check my python? I have never used python
before this and it was a significant effort in trial and error (I am not sure if the csv to list conversion is really necessary, but couldn't get it to work otherwise) 3) Also if so, should I "submit it" as another bug report in launchpad (or is there a different way to offer up an extension to the project)?
Yes, a bug report is the correct way to send it in.
Bryce
On Thu, 2008-01-10 at 09:30 -0800, Bryce Harrington wrote:
The performance issue and the need of calling a second instance of Inkscape suggests it might be better implemented as Inkscape C++ code than as an extension, but maybe one of the other extension writers knows a trick.
Yes, but I think until someone implements a C++ extension a slower Python extension is fine.
--Ted
Tomorrow I will post a cleaned up version of then extension at launchpad as a bug/feature enhancement. I have a zip with the py, inx and a couple of png samples explaining the result - I assume attaching this to the bug report would be adequate.
The performance is actually quite acceptable now that the --query-all command line flag is available, as a new instance of inkscape is called once instead of once per object in the selection.
Ultimately, when x, y, width and height of objects gets exposed by DOM it won't even have to make that call.
-Rob A>
On Jan 10, 2008 4:18 PM, Ted Gould <ted@...11...> wrote:
On Thu, 2008-01-10 at 09:30 -0800, Bryce Harrington wrote:
The performance issue and the need of calling a second instance of Inkscape suggests it might be better implemented as Inkscape C++ code than as an extension, but maybe one of the other extension writers knows a trick.
Yes, but I think until someone implements a C++ extension a slower Python extension is fine.
--Ted
I tested it and it works for me, so I vote for including it into 0.46. The only problem is that after the effect has run it says "cannot determine format, opening as svg", but I think other effects also suffer from this (is there a bug on this?).
On Jan 10, 2008 7:43 PM, bulia byak wrote:
The only problem is that after the effect has run it says "cannot determine format, opening as svg", but I think other effects also suffer from this (is there a bug on this?).
What OS is that under? (I don't see it using XP, but that doesn't mean much.)
And what other extension does it happen for? I'm guessing it comes from the call os.popen( "inkscape --query-all %s" % ( file ) )
and file is set like so: file = self.args[ -1 ]
So I am not sure why Inkscape would complain. I don't see the error when I just do inkscape --query-all test.svg from the command line...
-Rob A>
On Thu, 2008-01-10 at 20:43 -0400, bulia byak wrote:
I tested it and it works for me, so I vote for including it into 0.46. The only problem is that after the effect has run it says "cannot determine format, opening as svg", but I think other effects also suffer from this (is there a bug on this?).
This is caused by GTK+ creating the temp file incorrectly, it appends the random text on the end instead of the middle. It should be fixed in newer versions of GTK+.
The extension should be able to hide it using popen3:
[dontcare, care, dontcare2] = os.popen3('command')
That'll swallow STDERR and STDIN.
--Ted
Ted Gould wrote:
On Thu, 2008-01-10 at 20:43 -0400, bulia byak wrote:
I tested it and it works for me, so I vote for including it into 0.46. The only problem is that after the effect has run it says "cannot determine format, opening as svg", but I think other effects also suffer from this (is there a bug on this?).
This is caused by GTK+ creating the temp file incorrectly, it appends the random text on the end instead of the middle. It should be fixed in newer versions of GTK+.
Indeed! Bryce and I were just discussing this. It is Glib 2.11.4 or greater in particular. See my comment at:
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/exten...
I suppose we could make the pattern conditional (preferably using relaytool) on GTK version so that newer GTK users can benefit without breaking for older GTK users. We should also change this for autosave files to make them easier to find.
The extension should be able to hide it using popen3:
[dontcare, care, dontcare2] = os.popen3('command')
That'll swallow STDERR and STDIN.
Yup, and other extensions already follow that pattern:
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/ext...
The negative is that this could mask real errors.
Aaron Spike
I have cleaned up the code after passing it by someone with more python experience than I have.
I have changed to popen3 to swallow the error codes (oddly enough, they don't appear in the windows version - no stderr, I guess).
Attached in launchpad: https://bugs.launchpad.net/inkscape/+bug/182002
-Rob A>
participants (5)
-
Aaron Spike -
Bryce Harrington -
bulia byak -
Rob Antonishen -
Ted Gould