Python Extension Changes to getElementsByTagName?
Hi-
I couldn't find this in the bugtracker, so signed up to ask here Hope this is appropriate... has there been a change to the SVG handling in recent devel nightlies (win 32 binary versions)?
Several extensions I had written no longer work. I also discuvered the Hello World example from the wiki shares the same error. http://wiki.inkscape.org/wiki/index.php/PythonEffectTutorial
The error is:
Traceback (most recent call last):
File "share\extensions\hello_world.py", line 57, in <module>
effect.affect()
File "C:\PF\Inkscape\share\extensions\inkex.py", line 154, in affect
self.effect()
File "share\extensions\hello_world.py", line 29, in effect
svg = self.document.getElementsByTagName('svg')[0]
AttributeError: 'etree._ElementTree' object has no attribute 'getElementsByTagName'
Also, is there an option in the .inx file I can set to permanently disable the live preview check option? My extension take a long time to run (>30 seconds) and the live preview becomes a pain.
Thanks.
-Rob A>
On Tue, 2008-01-08 at 14:23 -0500, Rob Antonishen wrote:
Also, is there an option in the .inx file I can set to permanently disable the live preview check option? My extension take a long time to run (>30 seconds) and the live preview becomes a pain.
No there is not a way, but I don't see that as an issue. The live effect checkbox is disabled by default and if it is enabled the only thing that should change is that, in the background, it would start running before the user hits "okay" in the dialog.
Also, if we offered such an option I think our choices would become outdated quickly. When I get my new wiz-bang computer, it'll probably render it in 2 seconds, and make live preview useful.
--Ted
On k, 2008-01-08 at 12:02 -0800, Ted Gould wrote:
On Tue, 2008-01-08 at 14:23 -0500, Rob Antonishen wrote:
Also, is there an option in the .inx file I can set to permanently disable the live preview check option? My extension take a long time to run (>30 seconds) and the live preview becomes a pain.
No there is not a way, but I don't see that as an issue. The live effect checkbox is disabled by default and if it is enabled the only thing that should change is that, in the background, it would start running before the user hits "okay" in the dialog.
Also, if we offered such an option I think our choices would become outdated quickly. When I get my new wiz-bang computer, it'll probably render it in 2 seconds, and make live preview useful.
Let's consider the barcode extension (pick EAN8). With the live preview on, when you start, it complies (with an error message), that I should write 6 letters. And when i type one more letter, it popups an another error message, that the entry should be exactly 6 characters. So it does matter how fast your computer is...
Best regards, Khiraly
The error message:
Can not encode '1' into EAN8 Barcode, Size must be 7 or 8 Numbers only Traceback (most recent call last): File "/usr/share/inkscape/extensions/render_barcode.py", line 58, in <module> e.affect() File "/usr/share/inkscape/extensions/inkex.py", line 153, in affect self.effect() File "/usr/share/inkscape/extensions/render_barcode.py", line 49, in effect barcode = object.generate() File "/usr/share/inkscape/extensions/Barcode/Base.py", line 114, in generate text.set( 'xml:space', 'preserve' ) File "etree.pyx", line 534, in etree._Element.set File "apihelpers.pxi", line 199, in etree._setAttributeValue File "apihelpers.pxi", line 723, in etree._getNsTag ValueError: Invalid tag name
On Jan 9, 2008 4:54 PM, khiraly <khiraly123@...240...> wrote:
Let's consider the barcode extension (pick EAN8). With the live preview on, when you start, it complies (with an error message), that I should write 6 letters. And when i type one more letter, it popups an another error message, that the entry should be exactly 6 characters. So it does matter how fast your computer is...
Of course this checkbox must be off by default, we discussed this long ago.
Let's consider the barcode extension (pick EAN8). With the live preview on, when you start, it complies (with an error message), that I should write 6 letters. And when i type one more letter, it popups an another error message, that the entry should be exactly 6 characters. So it does matter how fast your computer is...
Err, few typos: 6 letters -> 8 letters 6 characters -> 8 characters So it does matter -> So it does NOT matter
Sorry for the inconvenience.
(Im in write-only mode ...;-)
Khiraly
On Wed, 2008-01-09 at 21:54 +0100, khiraly wrote:
Let's consider the barcode extension (pick EAN8). With the live preview on, when you start, it complies (with an error message), that I should write 6 letters. And when i type one more letter, it popups an another error message, that the entry should be exactly 6 characters. So it does matter how fast your computer is...
That's a good point, but I'm not sure that we want to disable live preview there. I personally like seeing the different bar codes before committing.
I'm thinking that perhaps the error messages should be suppressed until you commit. So it should fail silently until you select "OK." I'm not quite sure how to do that architecturally -- but it seems like the "right" answer. What do others think?
--Ted
I'm thinking that perhaps the error messages should be suppressed until you commit. So it should fail silently until you select "OK." I'm not quite sure how to do that architecturally -- but it seems like the "right" answer. What do others think?
The best method would be, if gtk.Entry change to red color.
gtk.Entry.modify_base(gtk.STATE_NORMAL, gtk.gdk.color_parse("FF0000"))
I dont know how is it implemented in gtkmm.
And the dialog should contain an error frame/notebook page. And if error occours, instead of popup, in the dialog should be reported.
What do you think?
Rob Antonishen wrote:
I couldn't find this in the bugtracker, so signed up to ask here Hope this is appropriate... has there been a change to the SVG handling in recent devel nightlies (win 32 binary versions)?
Indeed. After 0.45 we switched from the abandoned pyxml to lxml (which imho is much much better). If you have any questions about converting your effects to lxml, just ask. I found that there are just a few simple changes to make. You can check the diffs in SVN to see how most of them were converted.
Aaron Spike
On Jan 8, 2008 9:48 PM, Aaron Spike wrote:
Rob Antonishen wrote:
I couldn't find this in the bugtracker, so signed up to ask here Hope this is appropriate... has there been a change to the SVG handling in recent devel nightlies (win 32 binary versions)?
Indeed. After 0.45 we switched from the abandoned pyxml to lxml (which imho is much much better). If you have any questions about converting your effects to lxml, just ask. I found that there are just a few simple changes to make. You can check the diffs in SVN to see how most of them were converted.
Aaron Spike
Thanks Aaron -
I was able to get my code converted - just two change, .appendChild became .append, and the self.document.getElementsByTagName( 'svg' )[ 0 ] call became self.document.getroot()
The extension I wrote is to change the z-order the selected objects in one of the orthogonal directions, using a specified base point of each object. WOuld this be of interest to anyone else for inclusion? (I had posted it previously on the user list).
-Rob A>
On Wed, 2008-01-09 at 11:48 -0500, Rob Antonishen wrote:
The extension I wrote is to change the z-order the selected objects in one of the orthogonal directions, using a specified base point of each object. WOuld this be of interest to anyone else for inclusion? (I had posted it previously on the user list).
I think that it is generally useful, is it attached to an item in the bug tracker on launchpad?
--Ted
On Jan 10, 2008 1:05 AM, Ted Gould wrote:
On Wed, 2008-01-09 at 11:48 -0500, Rob Antonishen wrote:
The extension I wrote is to change the z-order the selected objects in one of the orthogonal directions, using a specified base point of each object. WOuld this be of interest to anyone else for inclusion? (I had posted it previously on the user list).
I think that it is generally useful, is it attached to an item in the bug tracker on launchpad?
No it is not. I had written it for my own use, then figured it might have more universal appeal. Right now I am converting it to use the --querry-all command line option recently introduced, which should speed up the executions time significantly.
-Rob A>
participants (5)
-
Aaron Spike -
bulia byak -
khiraly -
Rob Antonishen -
Ted Gould