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

Bug #1395452 reported by rickmastfan67
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

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.

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.

Related branches

Revision history for this message
rickmastfan67 (rickmastfan67) wrote :
Revision history for this message
jazzynico (jazzynico) wrote :

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).

Changed in inkscape:
status: New → Confirmed
tags: added: objects
tags: added: ui
Revision history for this message
su_v (suv-lp) wrote :

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:

Revision history for this message
jazzynico (jazzynico) wrote :

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"?

Revision history for this message
su_v (suv-lp) wrote :

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.

jazzynico (jazzynico)
Changed in inkscape:
importance: Undecided → Wishlist
status: Confirmed → Triaged
su_v (suv-lp)
summary: - Raise and Lower objects commands partially broken
+ Support Raise and Lower (z-order) for non-overlapping objects
Revision history for this message
su_v (suv-lp) wrote :

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:

Revision history for this message
su_v (suv-lp) wrote :

Earlier references from early 2004 which document current behavior as intentional:
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).

Related commit:

Revision history for this message
chr[] (chr0x07) wrote :


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

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 :)

chr[] (chr0x07)
Changed in inkscape:
assignee: nobody → chr[] (chr0x07)
Revision history for this message
Patrick Storz (ede123) wrote :

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).

Revision history for this message
Patrick Storz (ede123) wrote :

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

Revision history for this message
chr[] (chr0x07) wrote :

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.

Revision history for this message
chr[] (chr0x07) wrote :

update, please test.

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

Revision history for this message
Mc (mc...) wrote :

pushed into 0.92.x r15430, on wait for trunk

Changed in inkscape:
milestone: none → 0.93
status: Triaged → In Progress
Mc (mc...)
Changed in inkscape:
status: In Progress → Fix Committed
milestone: 0.93 → 0.92.2
jazzynico (jazzynico)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers