Support Raise and Lower (z-order) for non-overlapping objects

[rickmastfan67]

Inkscape 0.48.5 r10040
Windows 7 x64 SP1

Steps to reproduce:
1. Load the attached SVG.
2. Once the SVG is loaded, hit the 'TAB' button on your keyboard to cycle through the three colored shapes you see. They should go 'Light Blue > Green > Red'.
3. Now, select the 'Green' one and hit the 'Page Up' button on your keyboard (or do Object > Raise, doesn't matter which way it's done for this bug to happen) to raise it up the order of the shapes so that you can change the order of the tab cycle.
4. Now, un-select the 'Green' shape so that nothing is selected.
5. Now, do the TAB cycle again and pay attention to the order Inkscape cycles through the colored shapes.

What should happen:
Since you hit the 'Page Up' button on the 'Green' shape, it should have raised it so that the TAB order cycle of the shapes should now have become 'Light Blue > Red > Green'.

What happens:
The TAB order cycle stays the same as when you opened the file, 'Light Blue > Green > Red', indicating that Inkscape didn't do the 'Raise' command you issued via the 'Page Up' button.

Work-around:
If you substitute the 'HOME' key (Object > Raise to Top) for 'Page Up' in Step #3, the order is properly changed to 'Light Blue > Red > Green' for Step #5.

I discovered this bug when trying to put some shapes in order that I could TAB between them from Left to Right. No idea what is causing this bug to happen. Also, if I were to substitute the 'Red' shape in the middle and have done either the 'Raise' or 'Lower' option, it wouldn't have properly shifted order either. Now, if I were to put those 3 shapes in a way that they overlap each other just slightly, this bug doesn't happen and both the 'Raise' and 'Lower' commands in 'Object' work correctly.

Now, before you ask, this isn't a profile caused bug, as I can duplicate it when a brand new clean profile that Inkscape creates when there isn't one.

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape 0.91.x rev. 13791, 0.48.5, 0.47 and 0.46.

Weirdly nobody complained about it before (at least I can't find a bug report directly related to the issue).

[su_v (suv-lp)]

Based on my on experience (I encountered this behavior frequently), this might work as expected (or as implemented): raise / lower seems relative to an overlapping object. If there is no overlapping object, there is nothing to do.

See also the comment following this line:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/selection-chemistry.cpp#L980

[jazzynico (jazzynico)]

I also frequently run into the same issue too, but I was so sure a report already existed...

~suv> this might work as expected (or as implemented)

As implemented, sure. But it doesn't seem very handy (at least to me and the reporter), and is not consistent with the Raise to Top and Lower to Bottom commands, which don't need overlapping objects to work. (With LibreOffice Draw, all the raise/lower commands work even with non overlapping objects.)

Anyway, as it was designed to work as it does currently, I guess we should convert the report to a "Wishlist"?

[su_v (suv-lp)]

On 2014-12-09 15:33 (+0100), jazzynico wrote:
> Anyway, as it was designed to work as it does currently, I guess we
> should convert the report to a "Wishlist"?

IMvHO yes.

[su_v (suv-lp)]

Note that this would introduce two differing modes for 'Raise' and 'Lower':
- overlapping objects: raise/lower relative to the z-order of the overlapping object (any number of levels)
- non-overlapping objects: raise / lower 1 absolute level in z-order

Two different modes could be considered yet another inconsistency since the number of levels the commands apply differs depending on the selection, and can't be easily verified in the GUI using current 0.48 or upcoming 0.91. It will make more sense for the Raise/Lower buttons in the new 'Objects' dialog in current trunk (for 0.92) - they currently work the same as the menu commands and toolbar buttons in stable (only affecting overlapping objects).

An alternative solution to restack objects which does not depend on overlaps but on the position of the objects' bounding box on the canvas (likely what the user tried to achieve before filing this report) is offered by the 'Restack' extension:
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Extensions-Arrange.html#Extensions-Arrange-Restack

[su_v (suv-lp)]

Earlier references from early 2004 which document current behavior as intentional:
<quote>
And lest I forget, the raise/lower commands need to be rewritten so that the
selection, too, cycles through only the objects that overlap it, not all the
objects of the document as now (this presently makes lower/raise almost
unusable in large documents).
</quote>
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/1301>

Related commit:
<http://sourceforge.net/p/inkscape/code/2338/>

[chr[] (chr0x07)]

Hi

It's amazing this bug^W^w feature exists since the beginning of inkscape XD
Meanwhile people use inkscape to generate CNC code and I'd like to relay on the order of the objects to optimize my machine's movements.

I think it's quite easy to fix. The "Support Raise and Lower (z-order) for non-overlapping objects" already exists ;)

Actually this feature (PageUp/Down button tooltip) is labeled:

"Lower/Raise selection one step" ("one step ... of what?"):

but in fact it does:
Lower/Raise selection over/under next(!) overlapping object

fix: clarify description and assign this nice feature to keystroke ctrl+PageUp/PageDown

XML-Panel:
There is the function I'd expected on PageUp/Down

"Lower/Raise Node"

bug: actually can't assign a keyboard shortcut to this
fix: create kyboard shortcut and assign to PageUp/Down

Object Panel:

The buttons tooltip says: "Move Up/Down" but in fact .... see above.
Clicking that button feels like a bug if the object hangs in the list and doesn't move.

fix: reassign this buttons to "Lower/Raise Node"

and we are done :)

[Patrick Storz (ede123)]

Nice one... didn't even know the option worked like that. I always assumed it would just move objects up/down in the XML tree(explains why it was a bit unpredictable at times - I always blamed myself).

If we're counting votes I'm in favor of changing both (shortcuts and GUI buttons) to do just that. That would also make the "Lower/Raise selection one step" and "Lower/Raise selection to bottom/top" work consistently, as the two mentioned first actually allow to move to the top/bottom of the XML parent while the latter two apply some unclear magic to determine if objects are considered as overlapping (it does not work properly... might just be another bug).

[Patrick Storz (ede123)]

After some discussion on IRC and getting used to idea I never understood what the GUI buttons were doing I now support to keep the current behavior and potentially change the tooltips slightly (but it might be hard to find something concise).

However stack-based re-ordering might be implemented with using modifier key or in the new "Objects" dialog

[chr[] (chr0x07)]

The result of your testing was:

I've overseen that ctrl+pageUp/Down was already assigned to action "LayerNext"

My conclusion of the discussion:

Let the user decide.

I think I found a solution for the holy keystroke cow, stay tuned.

[chr[] (chr0x07)]

update, please test.

I found one bug: shortcut switch layer (ctrl+page) does not update panel

[Mc (mc...)]

pushed into 0.92.x r15430, on wait for trunk