GNOME Bugzilla – Bug 639946
easy place-sidebar/main-view switching with arrow keys
Last modified: 2012-09-18 14:58:02 UTC
hi, the GTK file chooser allows to easily switch between the places sidebar (or whatever it is called in that context) and the main file list using the left/right arrow keys. (try it, it's very useful once you get used to it.) it would be nice if nautilus allowed to do the same. the proposed behavior is like this: - when the places sidebar has the focus, pressing right will move the focus to the file view - when the file view has the focus, and there is a selected item, and it is in the first column of data (icon view, compact view) or just anywhere (list view), pressing left moves the focus to the places sidebar unless there are strong usability arguments agaist it, I will try to cook a patch.
Created attachment 179100 [details] [review] preliminary patch only handles the icon view and the places sidebar. I'm not super-sure about how to proceed for the tree view. please, let me know if the approach is completely off. thanks.
Created attachment 179438 [details] [review] proposed patch, take 2 New version of the same patch as before. Changes: - support for the list view - support for the tree sidebar - fixed a leak About the implementation: - in the patch, the "move the focus to the sidebar" operation is implemented by the icon view/list view by checking that the window is a navigation window, and which sidebar it embeds. This may not be acceptable. Perhaps implementing the operation in NautilusWindow may be cleaner. As for usability: - in the icon view, the behavior currently implemented by the patch inhibits the user from moving from the left-most icon on a row to the right-most icon on the upper row using the left key; this may be frustrating. Perhaps a better approach would be to allow moving from the sidebar to the icon view left-most icon using the left arrow. However, this requires a bit more hackery, and I am not yet sure how to pull it off. - currently, the tree sidebar reacts to up/down key events by opening the selected folder; this is in contrast with the places sidebar, which changes the selection but does NOT open it in the main view. I don't know which one of the two behaviors is desirable. Reviews and comments are warmly welcome.
Interesting idea, and I'm all for keyboard shortcuts. While I'm not a UI expert, I do have reservations: * Besides navigating the icon view, the keyboard is very nice for fine control over selection (Shift + arrow keys). Making navigation from the leftmost icon behave differently to other icons would indeed be frustrating when you want to select "icons in current row plus last one(s) in row above". * The left arrow key in the list view already has a defined, and useful, functionality. Pressing when on a child item within an expanded folder jumps up to the expanded folder (i.e. the parent of the selected item). There is even a patch that was just committed (bug 639688) which allows chaining the action: jump to parent, close it, jump to its parent, etc. It would be a shame to lose this navigation feature (either the old way or in its new, improved state). Maybe using a modifier key in icon and list view? E.g. Ctrl + Arrow key? (I don't know if that's already taken, just throwing it out there...)
Hi John, thanks for your input. A few comments: * Agreed, that's why I am not satisfied with the current patch. I tried to improve it by allowing to use the left arrow key, in the sidebar, to move to the right-most icon in the main view (the horizontally nearest one). However, it is not trivial (for me, at least) to compute which icon in the icon view whould get the focus, in this case. IOW, I have yet to find a way to do it. ;-) * In the list view, the left arrow functionality is overridden _only_ when the currently selected item is a root node, i.e., when it is in the leftmost column. This will conflict with the other patch you mentioned however, even if only in some cases. I don't really know what to do about it. * I was trying to avoid requiring a modifier to switch between the sidebar and the main view, to keep the interaction the most intuitive/easy possible. I think I'll wait for hints from the devs before going on with this patch. Thanks!
Hi, Stefano. Thanks for the follow-up! I think I understand what you mean by list mode, but I'm not sure we're talking about the same view. Are you talking about compact view? That's the only time I can think of where there's more than one column that's selectable. In the list view (icon + name + type + size + date modified), when an item is selected all the columns are selected. Or did you mean "root node" as in the topmost parent folder, in the case it's a folder? In that case, I'd understand it that if I'm in "B" below... (pane) A \-[B selected] ...pressing left arrow would move to "A"... (pane) [A selected] \-B ...and another press would move to the other pane... [pane selected] A \-B I guess that could work technically, but it still seems strange for an unmodified arrow to have both a navigational function (in the view) as well as acting as an interface function. It also would probably affect accessibility: I know that there has been a lot of debate in the past about selections that wrap vs. ones that don't. A wrapping selection means that you can't just hold down a key to scroll to a boundary and then lift it up to leave the end item selected - instead, what item remains selected is dependent on the user's reaction speed, which some people have trouble with. This navigation + interface navigation lead to a similar case: if a user held the key down too long, then he'd find himself in the left column instead of the file view. Further operations, such as "Enter", would have a different result than expected. Glad you're trying to think of all the angles! I hope that my input helps too.
(In reply to comment #5) > Hi, Stefano. Thanks for the follow-up! Hi John, > I think I understand what you mean by list mode, but I'm not sure we're talking > about the same view. Are you talking about compact view? That's the only time I With 'main view' I'm referring to whatever view you are using, e.g., icon view, list view, or compact view. 'Column' here is used in a very broad sense. In icon and compact views, 'first column' means all icons that are on the left border. In list view, 'first column' refers to root nodes. 'Last column' means the same thing, except that -- now that you make me think about it -- it is not well defined for the list view... I guess in this case it suffices to define 'last column' = 'first column'. Finally, just to be sure, list view is the one you switch to with CTRL+2 :-) > Or did you mean "root node" as in the topmost parent folder, in the case it's a > folder? In that case, I'd understand it that if I'm in "B" below... > > (pane) A > \-[B selected] > > ...pressing left arrow would move to "A"... > > (pane) [A selected] > \-B > > ...and another press would move to the other pane... > > [pane selected] A > \-B Exactly. > I guess that could work technically, but it still seems strange for an > unmodified arrow to have both a navigational function (in the view) as well as > acting as an interface function. I may seem odd at first, but *if* all corner cases are handled correctly (and it may not be trivial), it should become natural after a short while. The problem I'm trying to solve is that the place/tree sidebar are difficult to navigate to using the keyboard, and tabbing from the main view to the sidebar is painfully slow. I'm following the same approach used in the GTK file chooser, except that implementing it correctly in nautilus is harder (from a usability POV). > This navigation + interface navigation lead to a similar case: if a user held > the key down too long, then he'd find himself in the left column instead of the > file view. Further operations, such as "Enter", would have a different result > than expected. I see. I'd like to avoid using a modifier, but it may turn out to be a requirement after all... I'll have to think about it. > Glad you're trying to think of all the angles! I hope that my input helps too. It sure does! :-) Thanks.
(In reply to comment #5) > I guess that could work technically, but it still seems strange for an > unmodified arrow to have both a navigational function (in the view) as well as > acting as an interface function. It's all navigation of a sort, though, isn't it? I think it makes a lot of sense. > It also would probably affect accessibility: I know that there has been a lot > of debate in the past about selections that wrap vs. ones that don't. A > wrapping selection means that you can't just hold down a key to scroll to a > boundary and then lift it up to leave the end item selected - instead, what > item remains selected is dependent on the user's reaction speed, which some > people have trouble with. That's a good point... should probably investigate. > This navigation + interface navigation lead to a similar case: if a user held > the key down too long, then he'd find himself in the left column instead of the > file view. Further operations, such as "Enter", would have a different result > than expected. But it should be fairly easy to understand what has happened, at least. I would prefer to avoid the modifier key if at all possible - it would undermine what the patch is trying to achieve. CCing Calum. He loves stuff like this. ;)
Targeting 3.2 for this.
(In reply to comment #7) > CCing Calum. He loves stuff like this. ;) Gee, thanks :) Interesting, I didn't know this worked in the file chooser -- since GNOME 2.0, we've actually tried to get away from using the arrow keys for moving focus around in dialogs, because it's so hard to do robustly and predictably. IIRC the gtk guys were having a hard time trying to keep it working in the general case -- the comments above are a good example of the number of corner cases you have to accommodate, and that's with only trying to implement it for one specific window. Consequently, in the accessibility guide and other online help, we only really document Tab for moving focus between controls, and F6 for moving focus between panes (and in both cases, Shift to reverse the direction). Those shortcuts are implemented cleanly at the toolkit level, and indeed they work just fine in the file chooser, and in all Nautilus views. There are still some places where arrow keys work too, but we don't encourage users to find them :) Given the F6 shortcut already exists and works, and the problems already encountered in figuring out how to make this patch work well, have to say I'm not totally convinced that it's worth the effort --although admittedly F6 is a little-known shortcut, despite the fact it's been around and documented for years, and other platforms (Windows and Java, at least) use it too. That said, I'll go and have a play with it to see if I can think of any way that the arrow keys might work well enough without interfering with any of the current keynav. (Can't do it right now sadly, I only have 2.30 on this machine...)
Mass changing component for BZ cleanup, sorry for the spam.
I think I agree with Calum. We have Tab/Shift+Tab and F6/Shift+F6 that do this now. I am not sure we need another way. Using the arrow keys would also conflict with navigation within the pane.