changing current layer through an extension

[cosmin]

When trying to modify the current layer through a python extension, it doesn't work.

When I try to set up the inkscape:current-layer attribute through an extension, the expected behavior is that when the extension finish to execute, the current layer is modified, which is not the case. Take for example the code:

 nv = self.getNamedView()
 nv.set(inkex.addNS('current-layer', 'inkscape'), 'my_new_layer')

When this code is executed, I would expect that the layer with the id 'my_new_layer' is selected, but instead the same layer is selected (that was selected before executing the code). Please find attached a demo extension. Execute the extension. You will notice that although the output document contains the correct id in the inkscape:current-layer parameter of the named view, the selected layer remains unchanged.

[su_v (suv-lp)]

Possibly related:
'Live Preview' issue described in comments #16 and #17 of bug #789122.

[su_v (suv-lp)]

Nevermind the previous comment (doesn't seem related bug-wise, maybe slightly related to using methods to avoid creating objects in 'root').

[su_v (suv-lp)]

Similar comment by another extension developer:
<http://code.google.com/p/eggbotcode/source/browse/trunk/inkscape_contributed/eggbot_maze.py#386>

[cosmin (cosminadrianpopescu)]

Please find attached a patch for this bug. Copy the file inside the inkscape-0.48.1/src/extension/implementation and run

patch -i script.patch

Please note that the patch is made on the code downloaded from here: http://downloads.sourceforge.net/inkscape/inkscape-0.48.1.tar.gz

[jazzynico (jazzynico)]

Patch tested successfully on Windows XP, Inkscape trunk revision 10568.
More tests later on Ubuntu.

[cosmin (cosminadrianpopescu)]

I've tested the patch on Ubuntu before submitting it.

[jazzynico (jazzynico)]

Fix committed in the trunk, revision 10608.
Thanks for the patch!

[su_v (suv-lp)]

@JazzyNico - would you consider it save to backport the fix to the stable branch? It was originally written against 0.48.1, has no string changes, and maybe could be considered as bug fix rather than implementing a new feature.

(question based on an inquiry in #inskcape on irc about the bug status)

[jazzynico (jazzynico)]

@ ~suv - No objection. Tests in progress!

[jazzynico (jazzynico)]

Patch backported to the branch, revision 9836.

[su_v (suv-lp)]

Based on <https://bugs.launchpad.net/inkscape/+bug/944077/comments/10> I'm proposing to revert this patch (including the later changes to prevent bug #944077) in trunk and stable for now:

AFAIU the id "base" is not reserved for Inkscape's <sodipodi:namedview> object - the patch fails to work as soon as e.g. a different regular object uses this id instead, and/or if <sodipodi:namedview> has a different, autogenerated ID (usually something like "namedview1223"), e.g. if the current SVG document didn't originate in Inkscape itself, or had been saved as 'Plain SVG' at some point, or was converted from one of the supported other vector file formats.

The bug demo extension to change the current layer to a newly added one (with id "my_new_layer"):
- works, if <sodipodi:namedview id="base" …> (file was based on a default template)
- fails [1], if <sodipodi:namedview id="namedview1234" … /> and <rect id=base" … />
- fails, if <sodipodi:namedview id="namedview1234" … /> and no object has id = "base" (crash in 0.48.3.1)

Isn't there a more reliable way to retrieve and set the current layer information from <sodipodi:namedview> without depending on an arbitrary ID?

---
[1] Console warning from trunk after running the bug demo extension, if a regular object uses the id "base" (and <sodipodi:namedview> has an autogenerated id):
** (inkscape:44023): CRITICAL **: SPObject* SPDocument::getObjectById(const gchar*) const: assertion `id != NULL' failed

[jazzynico (jazzynico)]

Yes, we can select the namedview directly from the document.
Patch attached, tested (very quicky) on Windows XP only.

[su_v (suv-lp)]

> Patch attached, tested (very quicky) on Windows XP only.

Initial tests with Inkscape 0.48+devel r11563+789122-v2.diff on OS X 107.4 (using the test cases mentioned in comment #12) look ok, too. Will test with Inkscape 0.48.x later tonight.

Thx for looking into this :)

[jazzynico (jazzynico)]

Redirecting the patch and WIP status to Bug #944077.

[su_v (suv-lp)]

Backported patch tested ok with Inkscape 0.48.x r9904 on OS X 10.7.4 (64bit build)

(attached patch includes two white-space changes to match coding style of the rest of the document)