drag-and-drop should reorder layers

+1 on adding drag-and-drop for reordering layers. -1 for putting other types of objects in the layers dialog. What we really want is an object tree that also has layers, so we don't mess up the layers dialog for doing layer-specific things like Illustrator did.

See bug #181578

Confirm the drag-and-drop for layers part.

it's a couple of years I'm using Inkscape on regular basis... and I keep on trying to drag and drop layers to reorder them every single day.... maybe my brain is just stuck in the Gimp layer mode.. any advancement on this feature?

I just started using Inkscape and I immediately liked it but this feature is really missing.
Here's a somewhat silly question - how hard could it be for me to get in the code and implement this one?

this (and even layer nesting) can be done thru drag n drop within the xml editor (pressing ctrl shift x) so my question is why isnt implemented in the main gui? ty

Patch to enable drag and drop in the Layers dialog.
Should work for recursive nested (sub)layers as well.
Tested on Ubuntu 12.04 and Windows 7.

Patch tested successfully on Ubuntu 11.04.
Drag and dropping requires some dexterity when dropping between two layers, since the layer often drops as a sublayer. Is there a way to adjust a tolerance on the cursor's position?
Apart from that, it works as expected.
Great improvement. Thanks John!

Patch tested successfully on OS X 10.7.4 with X11 as well as Quartz [1] backend of GTK2 (2.24.10), using built-in trackpad (MBP) and external mouse (no tests done yet with tablet, nor whether the patch allows building with GTK3 (experimental)).

During the initial tests I did have some troubles grabbing a "current" (selected) layer using the build-in trackpad as input device (where grabbing an item requires a second tap), because this tends to switch to the edit mode (rename layer) most of the time. Thus with regard to this part of the original request:

> The Raise/Lower Layer buttons are completely superfluous in
> this context and should be removed in favour of drag-and-drop.

I'd vote to keep those buttons in the dialog (there are occasions where DnD is not feasible, and a quick click on one of the buttons is faster, easier accessible and more reliably "precise" with regard to the target position).

---
[1] Using the Quartz backend of GTK2 with this feature probably needs more testing (IIRC there are several open bugs reported upstream for GTK+/Quartz related to DnD, but I don't know whether those apply to this feature). During the initial tests (running from gdb) I didn't yet encounter a crash triggered by DnD in the 'Layers' dialog.

Patch tested successfully on OS X 10.7.4 with GTK3/X11 3.4.3 (experimental):
builds without failure, basic tests for DnD ok.

@JazzyNico, the logic for drop target selection is, drop into the top 1/3 of a row is considered a drop "before" the row, the middle 1/3 is a drop "into" (sublayer), and the bottom 1/3 is a drop "after". So you should have a 2 in 3 chance of dropping "between" rows ;)

To make it easier to drag the selected layer, we could change the inline layer renaming to only occur when the user double-clicks the layer. This is similar to the Gimp and in this patch.

I think that even though it's a change to existing behavior, I think it's a change for the better. It was an aggravation for me to accidentally bring up "renaming" when working with the dialog.

Is it possible to make the "dragged layer" (as in the full-size box from the dialog) show at 50% opacity so it's a little more visible with what is going on when dragging? I think the black line above/below would be much more obvious and maybe do either a line in the middle of the parent layer if it will be placed as a sublayer, or a line only halfway the width below the new parent layer.

The 1/3 split does make sense, I'm just trying to think of how to make it more obvious and user-friendly (I think the opacity/transparency thing would be a big step imho, if possible).

Shaping up nicely!

Nevermind my comment about the visuals for drop of a sublayer, I now see the highlighting the new parent layer... however, I still think possibly transparency of the dragged object would make it all more visible/obvious.

If everyone is ok with the change in functionality (rename requires a double click), I will commit to the trunk.
I haven't been able to override the drag icon transparency yet ...

I'm ok with it.

> I haven't been able to override the drag icon transparency yet ...

Oddly, this seems to vary with the GTK+ backend and/or GTK2 version: on OS X 10.7.4,
- x11 backend (stock gtk2 2.24.20):
   dragged item is fully opaque.
- quartz backend (gtk2 2.24.10 + patches from git branch [1]):
   dragged item is semi-transparent

Notes:
- Affects DnD in the layer diaolg as well as in the XML Editor.
- It doesn't matter which theme engine is used.

---
[1] possibly one of those later commits added this feature - I haven't updated the gtk2/x11 branch yet to use the same set of patches.

Correction (typo):
- - x11 backend (stock gtk2 2.24.20):
+- x11 backend (stock gtk2 2.24.10):

~suv (suv-lp) wrote
> [1] possibly one of those later commits added this feature (…)

Nope - seems to be a quartz-based feature supported only on OS X 10.7 Lion (e.g. no transparency of dragged item with the quartz backend (gtk2 2.24.10+patches from git branch) on an older version of Mac OS X (10.5.8) either)

@~suv, thanks for checking on the drag icon transparency across platforms.
What do you think about the having to double click the active layer to rename ? Do you think that is ok ?

John Smith wrote
> What do you think about the having to double click
> the active layer to rename ? Do you think that is ok ?

Sorry for the delay (I actually missed the second version of the patch somehow ;-) ). For me, a double-click to edit the layer name is ok (even better than before because renaming is also no longer triggered unintentionally when sloppily changing or reselecting the current layer). I don't know though what the GNOME HIG has to say about this.

Committed to trunk as r11526.

Minor detail maybe to be considered:
- if layer label has focus, allow to enter edit mode with <Return>, in addition to double-click with LMB

(works in GIMP 2.8 like this as well)

Crash on Ubuntu 11.04, Inkscape revision 11529, when dropping a sublayer under the containing layer.

Program received signal SIGSEGV, Segmentation fault.
0x0810d4c1 in firstChild (this=0x8b9e3d0) at sp-object.h:318
318 SPObject *firstChild() { return children; }

Full bt attached.

> Crash on Ubuntu 11.04, Inkscape revision 11529, when
> dropping a sublayer under the containing layer.

Reproduced on OS X 10.7.4 (gtk2 2.24.10), but only if a sub-layer is dragged out of its containing layer and dropped at the bottom of the (top-level) layer list. No crash if the sub-layer is dropped elsewhere as top-lavel layer (assuming several top-level layers with sub-layers).

r11531 should fix the crash (#25, #26)

r11532 - Edit layer labels using the keys <Return> or <F2>

didnt want to open a new bug when it is related to this,

 dragging layers from one level to another for me causes the whole tree of layers to collapse for some reason.

using r11729