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

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

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

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

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.

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

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/>

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

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

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

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.

update, please test.

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

pushed into 0.92.x r15430, on wait for trunk