GNOME Bugzilla – Bug 86274
Better on-drawable layer navigation suggestion
Last modified: 2008-06-05 06:35:27 UTC
This is a UI suggestion that would make the on-drawable layer navigation easier. Currently the move tool supports a mode where a user is able to select a layer by clicking on a pixel that's from that particular layer. In case there is many layers stack on top of each layer, the one that's on top is selected. This works well if one doesn't need to select, say, a layer below the top one. The situation is VERY common with high-layer-count images powerGIMPusers work with every day. The solution might be an aditional mode for selecting the layer with the move tool. First, take a look at the following mockup: http://jimmac.musichall.cz/screenshots/gimp-layer-nav-mockup.png The situation pictured there is when a user XX-clicks* on a pixel, a menu of all visible layers that have that particular pixel covered would show up in a menu like that and the user could then pick up the correct one. [*] The problem is that all basic modifier keys for the move tool are taken and they all make sense. Ctrl toggles between picking a layer and moving it and shift adds/links a layer. If Ctrl+Shift for poping up this menu sort of clashes with the concept, since one might want to bring this menu up and add it to the linked group for example, consider adding a new tool/function that could have a fast toggle-shortcut assigned (like the move tool has a spacebar).
Perhaps holding the mousebutton for, say 2seconds to pop-up the menu (in layer selection mode of course) would make perfect sense (including using the Shift logic). But I don't know if that's doable. Also it might not be intuitive - but this is an advanced user-option (those guys read books and manuals ;) so that wouldn't be a problem IMHO.
This could work yeah. On the other hand, I personally have learned to like the PageUp/Down to select layers, and the cursors to move them, so I *very* rarely use the mouse to move things around. Such are the different ways people have learned to use things :-) The problem is I never seem to move layes accurately enough if I use the mouse :-/ The cursor keys work perfectly for that for me.
I also use keys to select layers, or the dialog, then shift to avoid reselect when moving with mouse. Unification of keys should make it even better. But well, some people will find the proposed method nice too.
I did not even know that the PageUp/PageDown keys worked on the canvas! See also bug #51108.
You could have easily learned that they do by looking at the menu Image->Layer->Stack. The Page Up/Down keys are clearly documented there.
You are right. Altough in the version that I am currently using (1.2.3, Solaris), the shortcut keys in that menu are written as "Prior" and "Next". I have no such key on my Sun keyboard. But now I know what they mean...
X11 also supports the names Prior/Next for the PageUp/Down keys. Unfortunately XLookupString() returns the rather uncommon version Prior/Next on most platforms. In GTK+-2.0 this problem is fixed by forcing the use of PageUp/Down in gdk_keyval_name().
You are right again. ;-) Actually, some years ago I had an old keyboard (from a Sun3, I think) that had these "Prior" and "Next" keys. And some X applications like "xev" return "Prior" and "Next" for "PageUp" and "PageDown" because they use XLookupString() directly. Anyway, back to the original topic of this bug report: if the goal is to have a way to quickly select layers (faster than having to look at the Layers dialog or using the Page Up/Down keys), then I don't know if having to wait 2 seconds for the menu to pop up would be a good solution. What about Ctrl-Shift-Alt-Meta-Compose-Click? ;-)
I overshot with the 2seconds yes. MacOS with it's one-button-mice uses the 'hold-button' to get a menu quite often and it works fine. I think the regular click is like miliseconds, so 1s or even .5s could work?
A shorter delay could work, but on the other hand that would be the only part of the user interface using this way to access the menu (if I am not mistaken). So I would prefer to have another way that would be more consistent with the other parts of the current user interface. Even if this requires an ugly combination of modifiers...
That is true, but how about adding this functionality: selection tools: popup a menu consisting of 'select all', 'select all pixels of this color'. crop tool: show a menu with 'from selection', 'auto shrink' (moving the rest of the annoying pop-up dialog to the tool options). However I'm fine with a shortcut. Of course having an inter-tool shortcut/toggle like what we have for the move tool (spacebar) would bring the advantage of moving around layers without changing the current tool (Enter?).
One more note =) Would it be possible to give some visual feedback for the PageUp/PageDown functionality? Something like what Ctrl+Tab has - a small preview window.
How would you decide when to display and hide this small preview window? It works when the shortcut includes a modifier key because you can keep the preview window open as long as the modifier is pressed and then change the current application/layer/whatever when the other key is pressed, but that would not work so well for the shortcuts that use only a single key. We could have a small fixed delay (1 or 2 seconds) during which the preview window remains open, but I am not sure that it would work well. Also, I do not know where this preview window should appear: in the center of the screen? Close to the mouse pointer (which is not used for this action)? In the center of the active image/canvas? This could get in the way if the Raise/Lower function is accessed through the menus instead of using the shortcut keys.
The Ctrl+Tab shows it up on the cursor position, right? Either that or the image window center is fine. The fixed delay might work, but I agree its a bit clumsy. Perhaps this is just duplication of the Ctrl+Tab functionality anyway (Ctrl+Shift+tab for reverse order isn't working in 1.3 btw). Sorry for using the bugzilla the IRC way :/
> Would it be possible to give some visual feedback for the > PageUp/PageDown functionality? Something like what Ctrl+Tab has - a > small preview window. We could just hook the "alt-tab" popup also into the page up/down thingy. Would work best IMHO. I dont know about the macos like menu thingy - X11 does not have an 1 button mouse (except if you use a powerbook and dont bind the rest of the buttons to keys :) It would be a bit confusing. Lets think first: * What task are you trying to do easier with such enchangements? * Would there be another way to do it? * HDPSDI*? I am all for cool new things in the Gimp, but overloading every button and key modifier with a million things makes it impossible to remember everything :-/ (* How Does PhtoShp Do it? :^)
Just to clear any possible confusion: PageUp/PageDown are essentially redundant fuctions to Ctrl+Tab, Ctrl+Shift+Tab (also alt+, but that's usually taken by a WM). The Ctrl+Tab is better in that it gives a visual feedback on what layer I'm actually switching to. The layer-select-menu pictured on the mockup is useful in the same situation for which we use the 'layer select' mode of the move tool, except when we don't want to select the topmost layer (The ctrl+tab cycles ALL layers, regardless of the curso position).
Well, the difference is that the Page Up/Down shortcuts are assigned to menu entries (<Image>->Layers->Stack->...) and can be re-assigned dynamically by the user. So if these shortcuts are not easy to use (e.g. on some old laptop keyboards) then they could be replaced by something more convenient. On the other hand, I think that Ctrl-Alt and Ctrl-Shift-Alt are hardcoded shortcuts that cannot be changed easily by the user (maybe I am wrong?). So both of them are useful IMHO. Also, the small preview window that is displayed when you press Ctrl-Alt could not be displayed if you access the same function from the menu. So in this case we have two separate features that are partially redundant, both of them have some drawbacks but I do not see any easy way to merge them into a single feature that would work from the menus as well as from a keyboard shortcut.
Not Ctrl+Alt, but Ctrl+Tab. It is already implemented. Does exactly what PageUp does. Ctrl+Shift+Tab is broken in HEAD.
Yes, sorry, I meant Ctrl-Tab, not Ctrl-Alt. I don't think that it would work well when invoked from the menus. So the two features are not completely redundant, even if there is a lot of overlap.
I think Ctrl+Shift+Tab does not work either in 1.2 (1.2.3, have not updated for some time and a bit busy for some days). Can anybody test it in recent 1.2? Also, what about Control + MB3 to get the layer menu? It could expand to other things, like Brushes, Gradients and so on, using also Shift and / or Alt if needed for different tasks (tool option vs brush type, ie). Menus under pointer are great, IMO, and modifier keys could give menus related to the tool or situation. Other thing (maybe not for this case) is the keys before vs after click, like selection tools. If anybody see it fitting anyway, it could be another solution. Have to think more if it makes sense here or not.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
I am willing to pick this enhancement request back up but it would probably be nice if one of the power users could summarize the request again and check how to fit it into the current UI. I also wonder how the the proposed popup menu is supposed to deal with lots of layers.
Jimmac, Tigert, could you try to summarize the outcome of this discussion to make it easier for someone who wants to implement this request?
I'd say the ctrl+(shift)+tab and pgup/dn behavior is good enough for now. It may be nice if the border of the layer changed on the canvas to, say 2px stroke for the active one. Closing.
*** Bug 341433 has been marked as a duplicate of this bug. ***
Hi Would it be possible to implement a simple switch to the 'move' layer tool. The problem: In order to locate a layer within a large psd file (containing over 400 layers) I currently have to select the layer using the move tool and then remember it's name and try and gauge where in the layers dialog it is located. I then have trawl through the layers dialog and attempt to locate it. Sometimes I work on compositions with almost 1000 layers... clearly this scenario become intolerable. Far too much time is being wasted 'locating' layers. The solution: The 'move' tool currently moves and shifts focus to a layer when the left mouse button is pressed and held. You will notice this behaviour if look at the layers dialog when a layer is selected using the move tool. So far, so good... However, as soon as the mouse button is released, gimp reverts back to the previous layer. In my opinion gimp already shifts focus to the new layer and a simple switch to signal NOT to revert back to the previous layer is all that is required. The switch could default to the current behaviour but offer provide the ability to retain focus on the 'moved layer'. This should be a simple case of "do we call function X to revert back to previous layer Y or instead remain on the new layer Z"
William, your request is not related to this bug-report and it is already implemented. The preferences dialog allows you to activate this behaviour of the Move tool (move-tool-changes-active). Please do not add further comments to this bug report as that would only distract from the original topic.
This report is confusing to say the least. Jakub proposed to close it in comment #24. Let's do that. If someone has a good idea for improving layer selection, then please bring it up on the gimp-developer mailing-list so that we can discuss it before opening a new bug report for it.