GNOME Bugzilla – Bug 79223
arrow keys to open folder
Last modified: 2004-12-22 21:47:04 UTC
Like the mac, alt-down should open the folder. It is then easier to navigate to a folder using the cursor keys and then open it without taking your right-hand off the cursor keys (as required by [ctrl]-o at the moment). It's also less keys to press. We need to use [alt] for this because [ctrl]-arrows moves the focus in GTK+ (I think - it might be a WM thing). I have no idea what the point of that is.
(Back reference) Bug report #79150 is related to this. I don't know why Ctrl+Arrow moves focus in gtk either. Calum?
I think this is a good idea. I very much enjoy the cmd-up / cmd-down in Macos. We probably could also make alt-up to go "up". This would be very straightforward for "open in current window" -setting. Just make "alt-down" an alias to "ctrl-o" and "alt-up" alias to "ctrl-u". What I would like in addition would be that with "open in separate windows" setting, alt-up would open the "parent folder" as well - meaning it would either focus and raise it if it is open, or open it in a new window if it is not open already. This is very useful on macos. Too bad Ctrl is taken for gtk focus navigation, I might personally have preferred to swap these around, but using alt is reasonable too.
lovely of bugzilla to "throw away my changes" and there they are in double.. :-)
Hey, what's with removing the CC list? ;-) I just remembered that Netscape set a precedent for using Alt+[Left|Right] as back and forward. I guess I need to find something else to raise/lower windows, again. (Not really complaining, just noting.)
So, contrary to my original comment, it's ctrl-down, not alt-down that does this on the map. tigert confused me. I still _think_ that it's alt-dbl-click on the Mac that does the same thing with the mouse, so if we use alt for both then we'd actually be more consistent than the mac.
s/does this on the map/does this on the Mac/
It also sounds like the Mac _always_ opens in the same window when using the keyboard to open the folder. And I think this is what tigert wants. However, I think it should just do whatever the mouse would do. That would be simpler.
Maybe there's some confusion here because of the views? I think the tree view and the icon view on the Mac have different keybindings. The Warp3 tree view, which displays only folders (afaict), uses '+' and '-' to open nodes; that's the only way you would have things opening in the same window. When things are opening in the same window, you lose the saved position of objects; either at that instant or at a later one. (Another confusing thing is that Mac keys don't map 1:1 to PC keys.)
I'm talking about the main right-hand-side icon/list view. At the moment I am ignoring the TreeView in the left-hand sidebar. I can't even look at that now because it doesn't exist in my cvs nautilus2. What makes you think that there is confusion due to the existence of the 2 views. I think we're on safe ground if we map the Mac's Option/alt to Alt, and Command to Ctrl.
I meant the tree views as I recall from Mac Finder and as in Warp3, not the side-panel of Nautilus. Both of these are first-class views and not relegated to a side-panel. (I don't think either of those has side panels.) Some Macs (all?) also have a Control key and that's not the same, afaik, as the PC Control key. Murray said, "tigert confused me." Comparing two systems with different types of views and keys can be confusing, so I wouldn't blame tigert. ;-) I understand the keybindings in the Finder tree are different from those in the icon folder views, though I haven't confirmed it myself. If one person were speaking of an icon view in Nautilus and the other of a tree view in Mac Finder, that might be confusing to compare.
Alex has implemented this, but it is still blocked by the default Sawfish2 bindings. See #80529.
If it is code-implemented in nautilus and works in metacity then this should be closed.
I don't know about metacity - I don't use it. While this is technically no longer a Nautilus bug, until our window managers are fixed it remains a GNOME2 bug.