GNOME Bugzilla – Bug 692349
Poor placement of "Floating selection" entry in Layers dialog
Last modified: 2015-02-14 20:07:22 UTC
In GIMP, any time there is a floating selection in the image the Layers dialog displays it at the top of the layer stack. But floating selections are not necessarily the top item in the layer stack, they're inherently linked to a source drawable and their actual position is just above the source layer, which may have other layers above it. For example, create the following layer structure: - Layer C - Layer group - - Layer B - - Layer A Then create a selection on layer A and float it. The Layers dialog now displays: - floating selection - Layer C - Layer group - - Layer B - - Layer A This is incorrect. In any other context top of stack means top of the stack, but that is not the case here: the floating selection is attached to layer A. Its logical placement is actually inside the layer group, between layers A and B: - Layer C - Layer group - - Layer B - - floating selection - - Layer A This is how the Layers dialog should display it. Matching the actual display order, and as a bonus it makes it clear which layer the floating selection belongs to - always the entry right beneath it. (PS: actual functionality is not a problem here - only how it's displayed by the Layers dialog.)
Note that Bugzilla isn't really the best place for discussing new behaviors.
I mentioned this on the gimp-user mailing list first. Should I forward a copy to gimp-developer?
No, the issue is completely known, and a fix is planned for ages, it's just very complex to fix, requires changes to many places, and has a high risk of breaking stuff. -> 2.10 so it stays on the radar this time.
The Feature Roadmap [1] has this feature in the 'Future - without milestone' section, while it is here postponed for 2.10. The information on the roadmap is from March 2011 - updating it with the newer info from this bug. For the sake of completeness: strata_rangers posting and the follow-ups can be found at [2]. There was also a discussion on this in 2006 - with involvement of an interaction expert - at [3]. This discussion also mentions bug #561576. I'm not really sure whether this is a duplicate of bug #561576, thus I only linked them together as related bugs. [1] http://wiki.gimp.org/index.php/Roadmap [2] https://mail.gnome.org/archives/gimp-user-list/2013-January/msg00073.html [3] http://www.gimpusers.com/forums/gimp-developer/12672-gimp-ux-paste#message58351
Definitely not a duplicate of #561576. It is true they're related to the whole floating selection issue, but in different ways - #561576 is about having an easier way to convert the floating selection into a new layer, this is simply about its visual placement in the Layers dialog.
Created attachment 296516 [details] [review] adjust floating selection layer placement With the patch attached, I have tested lot of basic manipulations on a complex layers hierachy (several nested layer groups) without noticing problem, with each time, a different active drawable (layer, layer'mask and channel) : - creating floating sel from a selection - creating floating sel from a seletion by using transform tools in layer mode - creating floating sel from clipboard (pasted) - creating layer from floating sel - anchoring floating sel - deleting floating sel - saving and loading xcf file containing floating sel - ... A real issue I see is for plugins which create a new layer from a floating sel, since plugins logic expect to have the new layer at the top of the layers' stack. But I don't have investigated yet all plugins to find them...
"""A real issue I see is for plugins which create a new layer from a floating sel, since plugins logic expect to have the new layer at the top of the layers' stack. But I don't have investigated yet all plugins to find them...""" As one who have written several plug-ins/scripts including some that made use of the floating-selection, I don't ever recall relying on the "new layer from floating sel" position on the stack. The "gimp_floating_sel_to_layer" call returns a reference to the new layer, and if there is any code that instead of using that would try to fetch a new reference to it in a fixed place in the stack, tat code can safely be assumed as broken.
The actual goal is to solve the floating selection stuff differently, but this is clearly a good step. Will test your patch.
Pushed a slghtly modified version of your patch, and forgot to change the commit log to say what the change actually does :/ commit ea5adf4ac0ec01e676510e5f4f005cd5df67a011 Author: Thomas Manni <thomas.manni@free.fr> Date: Tue Feb 10 13:56:54 2015 +0100 Bug 692349: Poor placement of "Floating selection" entry in Layers dialog app/core/gimplayer-floating-sel.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)