GNOME Bugzilla – Bug 127396
Metacity should not use the Alt-Ctrl-Arrow keybinding.
Last modified: 2004-12-22 21:47:04 UTC
As mentioned here: http://lists.gnome.org/archives/nautilus-list/2003-November/msg00093.html Nautilus needs one of the *-Alt-Arrow keybindings to implement MacOS-like keyboard navigation. For Nautilus, and for Metacity, we decided that Ctrl-Alt-Arrow would be the best one to take from Metacity. Is this acceptable?
There is certainly no consensus on this. 1) It has not been shown that there is any need for or benefit from Mac-like keybindings. 2) Consideration of Shift as a modifier for Nautilus was dropped without proper consideration. Metacity can almost certainly drop its Alt+Shift+ combos. See bug #126674 3) The effect on our CUA-like scheme has not been considered. 4) The effect on current users has been dismissed despite the lack of demonstrated benefit.
I believe it has been considered in that thread. It's the maintainer's preferred choice, while also considering the needs of Metacity. No, we have not done a detailed videoed user study. Regarding the CUA thing, I've never seen anybody but you say that it's a requirement for GNOME, or that it's a requirement that should outweigh everything else. If there's an actual conflict, then please bring it up, ideally in that email thread. Please don't swamp this little bug report.
I'm not even going to bother.
People are going to whine about the change, for sure. Does anything replace ctrl+alt+arrow for metacity?
> Does anything replace ctrl+alt+arrow for metacity? In the email thread, Alexander Larson wrote: > * I consider this form of workspace switching quite > inefficient, and I think heavy users of workspaces already > mapped up Ctrl-Fn or similar to immediately go to the right workspace. > * Causual users can use the workspace switcher Personally I think the workspace switcher is enough.
I use it constantly, and I'm a very heavy user of workspaces. The directional bindings are more intuitive than a numbered binding, especially if you have more than one row of workspaced.
Havoc, any chance of a decision?
Well I don't really know how and by whom such decisions should be made, but I would think that we should have a very good reason to switch around keyboard bindings before doing so. Why exactly can't nautilus use one of the numerous other key combinations?
> Well I don't really know how and by whom such decisions should be made I think the metacity maintainer + the nautilus maintainers should be enough. Would you like me to get a consensus on the Usability list too? I don't think that will be difficult. I promise to announce the change on desktop-devel list before anything is actually committed, but I don't want to waste peoples' time if it can't get that crucial Havoc approval. > Why exactly can't nautilus use one of the numerous other key combinations? 1. We would like *-Arrow because that allows very easy File Manager navigation. For instance, you can do Down, Down, Down (to select the 3rd item),Alt-Down (to open it), Down, Down (to select the 2nd item in the 2nd window), Alt-Down (to open that one too. We this already works. It's nicer than Down, Down, Enter because you then take your right-hand off the arror keys to press Enter. We would just like to add Ctrl-Alt-Up/Down to say "Open and close the current one". That is also more logical than pressing a completely different key because you are just slightly modifying the behaviour of the Alt-Down open-this-item key combination. This is all very familiar to Mac users, and has proven to be very useful. It make a very significant impact on usablility, particular with the spatial file manager. It's hard to persuade you without showing it to you on a Mac, but I am convinced that, if we implement it, it will be far more loved in future than any funky WM keybinding. 2. We can't use Shift-*-Arrow instead of Ctrl-*-Arrow because shift is used for multiple selection. That is even more of a problem when you realise that we need to use the same "and close the current one" modififer when double-clicking. 3. We can't use Alt-*-Arrow instead of Ctrl-*-Arrow because we are alrady using Alt. We need something for *-Alt-Up/Down, and that would be Alt-Alt-Up/Down. 4. We can't use the meta/super key because that's not on every keyboard, and when it is it is the funky windows key.
The alt-down to open thing seems really weird. So alt-down opens the folder that gets moved into? Enter seems much more intuitive, though I suppose you could do both. But really (traditionally anyway) the multi-modifier shortcuts are system-level shortcuts, and the single modifer ones are application shortcuts. Nautilus needs four things: 1) move around (unmodified arrow) 2) select while moving around (shift-arrow) 3) open folders as you move into them (alt-arrow) 3) open folders and close the old one as you move into them (?) Seems like the natural thing to put in that "?" is "Ctrl-arrow". Or is that yet another thing?
> alt-down opens the folder that gets moved into? alt-down opens the selected folder. This is already implemented in Nautilus. ctrl-arrow is used for accessibility focus movement. Please read the thread. re. Enter, please ready my comments above, and in the thread.
Well, I'm not just going to make a decision up. ;-) If Alex and two of Calum, Seth, Gregory think it's OK then that's good enough for me I suppose, my .02 would just be that I think a fair number of people are using the metacity binding so let's be sure changing it is worthwhile.
Assuming for the moment that Alt-Up/Down makes sense for Open Folder/Parent in nautilus, I'd be inclined to suggest that Shift-Alt-Up/Down makes more sense for "Open Folder/Parent and close this window". When used in a shortcut, Shift is supposed to "extend or reverse" the meaning of the unshifted shortcut (according to the HIG), which seems spot on here. Metacity currently uses Shift-Alt-arrows to mean "move this window to the workspace left/right/above/below", though. If we thought these were used less often than the shortcuts for "switch workspace" (which is certainly true of my own personal usage), could we make a case for relieving metacity of those instead?
I agree with Calum that the Shift-Alt-Arrows is probably the best binding to take away from metacity, in the sense that I would argue it's the least used key-binding and the combination can fit the mental model for navigation. I'll be sad to see the Shift-Alt-Arrows go from metacity, but I think I only use it once in a while anyway.
Regarding the use of shift instead of ctrl, as I said above: " 2. We can't use Shift-*-Arrow instead of Ctrl-*-Arrow because shift is used for multiple selection. That is even more of a problem when you realise that we need to use the same "and close the current one" modififer when double-clicking. " Alex pointed that out here when I suggested Shift originally: http://lists.gnome.org/archives/nautilus-list/2003-November/msg00056.html In that post he also suggests that this is the most appropriate binding to remove, which you might find interesting. I consider that HIG recommendation too vague to be binding, particularly as there can be more than one way to "extend" an operation.
> We can't use Shift-*-Arrow instead of Ctrl-*-Arrow because shift is > used for multiple selection. Shift-arrow is, but surely Shift-Alt-arrow isn't? Shift-arrow is supposed to extend a selection, Ctrl-arrow is supposed to move the focus without extending a selection. (Currently Ctrl-Shift-arrow does this too, but that's just a needless redundancy that should be removed). Alt is never supposed to be involved in selection activities, so AFAIK Shift-Alt-arrow should be free (other than it's current use in metacity).
> > We can't use Shift-*-Arrow instead of Ctrl-*-Arrow because shift is > > used for multiple selection. > > Shift-arrow is, but surely Shift-Alt-arrow isn't? The problem is that we want the same modifier key to mean "and close the current one" when double-clicking. Shift double-click will change the selection: http://lists.gnome.org/archives/nautilus-list/2003-November/msg00061.html > Alt is never supposed to be involved in selection activities. Is there any powerful reason for this, or is it just that the HIG does not anticipate the need for an extra modifier here?
> The problem is that we want the same modifier key to mean "and close > the current one" when double-clicking. Shift double-click will change > the selection It does currently, but that's just broken... that doesn't happen on Windows or Mac, for example. Even if there was a reason for Shift+doubleclick to change the selection, why should Shift-Alt-doubleclick do it as well? Surely it can't be hard to check if Shift+Alt is held down when you get the click events, and do something different if it is...? > Is there any powerful reason for this, or is it just that the HIG > does not anticipate the need for an extra modifier here? Just historical reasons, really... since the CUA days (and possibly before), Alt has always used for navigation and window manager commands, and Ctrl and Shift for shortcut and selection features. Nowadays, it's consistent with both the major commercial desktops, so that's what we decided to stick with.
>> Shift double-click will change the selection > > It does currently, but that's just broken... that doesn't happen on > Windows or Mac, for example. It does on My Windows 2000. Select several folders. Shift-double click the middle one. The selection changes (and Windows 2000 opens all the selected folders). I can't think how to do make the first click of a double-click do something that's not wanted by the double-click, without waiting to see whether the 2nd click happens. Wouldn't that be unresponsive. Even if we could do it, wouldn't you find it counterintiutive that one application (Nautilus) used the same modifier in the same place for 2 completely different things? Shift-click-release-move-click feels top much like shift-double-click to me. > Even if there was a reason for Shift+doubleclick to change the > selection, why should Shift-Alt-doubleclick There is (will be) no Shift-Alt-Doublelclick. I am suggesting Ctrl="and close the current one, meaning Ctrl-Doubelick to "open and close the current one", and you are suggesting Shift-Doubleclick instead. > it's consistent with both the major commercial desktops CDE and Windows?
> It does on My Windows 2000. Select several folders. > Shift-double click the middle one. The selection changes > (and Windows 2000 opens all the selected folders). Oh, if you doubleclick in the middle, sure... that's a little different. My apologies, I thought we were just talking about clicking the start of the range, then double-clicking the end of the range. > I can't think how to do make the first click of a double-click do > something that's not wanted by the double-click, without waiting to > see whether the 2nd click happens. Wouldn't that be unresponsive. If we were only to allow one folder to be opened in this way at a time, we wouldn't really need the first click to do anything, in the <whatever-modifier-we-choose>-doubleclick case (unless you were in single click mode of course).. it could just select and open the folder you double-clicked on when the second click was received, and do nothing if the second click was never receieved. (Perhaps that wouldn't be such a bad restriction actually... I know I've opened multiple folders by mistake a million times more often than I've ever wanted to open multiple folders on purpose!) > There is (will be) no Shift-Alt-Doublelclick. I am suggesting > Ctrl="and close the current one, meaning Ctrl-Doubelick to "open and > close the current one", and you are suggesting Shift-Doubleclick > instead. No, I am suggesting Shift-Alt-[arrow or doubleclick] to mean "and close the current one". That would leave us a minor non-orthogonality in that Alt-doubleclick isn't required to open a folder but Alt-arrow is, but that still feels like less of an issue than stealing frequently used metacity shortcuts to me. (Incidentally, whatever modifiers we choose should probably work with Backspace and Enter as well as down and up arrow respectively, but that's probably a separate issue :)
Closing, in favour of bug 129263, because Nautilus now uses Shift instead of Ctrl for this, after lots of discussion.