'Live Preview' toggle unsets current layer if nothing is selected

Attaching minimal test case (extension which reports current date, and the number of selected objects)

Confirmed on Debian testing, Inkscape trunk revision 11956.

Apparently affects external scripts only, not the internal ones (tested with some filters and the Grid extension).
Something wrong in inkex.py maybe...

... or in the extension/implementation/script.cpp specific code.

Can also be reproduced with:

1) open 'Extensions > Color > Randomize…'
2.a) select an object.
2.b) keep the selection empty.
3) apply the extension.
4) undo.

The selected layer is now root.

5) redo.

No change, we're still in root.

The reason it doesn't happen when toggling live preview with a selection could be the call to 'reselect()' after the undo:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/extension/execution-env.cpp#L169

Could this be a limitation of the extension architecture that the current layer is initially not set after the document content is replaced with the output of the effect extension script, and the 'reselect()' causes the current layer to be restored to the layer of the first object in the selected items?

AFAIU changing the current layer is not recording in the undo history, and - if no selection existed - can't be restored by undo (or toggling live preview on/off again)…

~suv wrote:
>JazzyNico wrote:
>> Apparently affects external scripts only, not the internal ones

> the current layer is initially not set after the document content
> is replaced with the output of the effect extension script

Which could also explain why internal extensions are not affected: AFAIU they don't have to completely replace the current document content with the output they generate, since they access the XML tree internally directly - hence the current layer level is not modified unless explicitly triggered by the extension?

I can't seem to repro, not with comment #7 either.

I do get this when enabling Live Preview:
  File "color_randomize.py", line 23
    self.OptionParser.add_option("-o", "--opacity_range",
                                                        ^
TabError: inconsistent use of tabs and spaces in indentation

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15073 (GTK3)

Still reproduces with
- Inkscape 0.91 r13725 (OS X 10.7.5)
- lp:inkscape/0.92.x r15044 (OS X 10.7.5)
- lp:inkscape r15036 (OS X 10.7.5)
- lp:inkscape r15077 (Ubuntu 14.04.5 LTS)

--
@Beluga - you are unlikely to revisit this report, but anyway: Inkscape's python-based extensions are not yet compatible with Python 3, you need to make sure that Inkscape spawns the Python 2 interpreter (first 'python' binary in $PATH; else patch the source to force it to spawn 'python2' explicitly), and have Python 2, as well as the lxml and numpy modules for Python 2 installed. There's no point though to litter the fact about your local partially broken setup across the bug tracker: if you can't figure it out yourself, ask for help e.g. on irc or on one of the mailing lists, or - if you installed unstable Inkscape trunk via package maintained by your distro (archlinux: inkscape-bzr) - file a report there to properly manage python migration (python2 -> python3) for all packages they offer. IIRC last time I checked, the official arch linux packages for inkscape and inkscape-bzr did ok (patching the source to substitute 'python' with 'python2' for the interpreter, with (optional) dependencies on the python2 modules; though oddly no explicit runtime dependency on python2 itself (?)).

Not replicated in 0.92.4 and 1.1-dev (c990a67, 2020-04-09), Windows 10. Marking as Fix Released.

Please reopen on http://inkscape.org/report if the problem occurs again.

Closed by: https://gitlab.com/jhofinger