GNOME Bugzilla – Bug 118358
ENTER in tree view could expand/collapse
Last modified: 2009-08-15 18:40:50 UTC
So could Ctrl+Right arrow (expand) and Ctrl+Left arrow (collapse). Or Left/right in tree view could act as collapse/expand, while horizontal scrolling would be removed (tooltips could be used for displaying the full title of the node).
I don't think we should change the default behavior of the treeview in GTK+. Shift-arrows expands/collpses nodes, and tooltips on treeviews are currently not possible with GTK+. It's in the plans for GTK+ at some point though.
I think it's a bit conservative an approach, and surely not the optimal one. I've sent an analysis of the subject to the gnome-devtools mailing list, please read and make up your mind in the light of it: http://mail.gnome.org/archives/gnome-devtools/2005-September/msg00003.html
Sorry, I didn't mean to close the bug yet, just to add my comment above. I agree that the horizontal scrolling is useless and should be disabled (I've done it in my local tree, will commit it asap). And I do agree that we need to improve keynav, but I also think that the standard keybindings used in GTK+ and GNOME should be used as far as possible to have consistency. I really don't agree that ctrl-arrow is better than shift-arrow, at least not on my keyboard, for what it's worth. (For power users, it's not that hard to change the keybindings in GTK+ by the way, see the docs on keybindings in the "Resource Files" in the API reference docs.) I tend to think that improving other parts will help a lot more, such as adding bookmark support, support for searching just in certain books or collections of books, in-page searching, etc. Also improving the current search mechanism is something that I would like to do.
Well, I just gave Ctrl+arrows as an example, Shift+arrows seems to be fine too (except the fact that Shift+arrows are traditionally used for range selection, but range selection isn't necessary in this context). Just not Alt+arrows because they're reserved for history navigation. Optimally, horizontal scrolling shouldn't be necessary at all, so any key choice is good. I agree about bookmark support. I haven't seen tabs support that was sent to the devtools list recently yet, but the idea seems to be a great improvement (it's a common thing to need multiple pages at the same time, and the current version didn't support it at all). However, it seems to conflict with the idea of changing page on selection. But that's where Enter key to open the book seems to be help. I've ignored the search part of DevHelp for now, in order to concentrate on one thing. It's not a real search anyway, just a title search - but that's usually even better. I don't really like the fact it dynamically changes when I type in it, but I didn't explore it for now. Subset searching - other help systems have it, but would you actually use it for GNOME books? I guess it's also meant to make up for lack of book display in search results (which, on the other hand, would clutter the result window). In-page searching - great idea! Also, what about a function to find a current page (found using search function) in a content pane? M$ did it, and it's surely useful. All in all, I think all the ideas you've suggested are of higher priority. I'll try to look at keynav problem myself once your horizontal scrolling patch is committed.
Created attachment 52810 [details] [review] Enhanced key navigation
The patch implements the following ideas: - right/left arrow navigation for expanding/collapsing nodes - enter for selecting the document from a content pane, esc for going back to content pane (not a perfect solution, but better than any other I can think of) Feel free to comment
I don't want to add code to handle keybindings (for expand/collapse), since there is already a mechanism in GTK+ for that, as I mentioned above. It can be used both to override bindings by the user, and to ship certain bindings with the app. Using Escape as done in the patch is out of the question in my opinion, it's just too much different from what Escape is used for in the rest of the desktop. It's used to cancel things, not arbitrarily change focus in apps. With the current behavior of the book tree, the Enter binding is bad as well, since pressing enter wouldn't do any kind of activation, just switch focus. It's not what I would expect. It could make sense if we changed the tree to not select the node when moving up and down in the tree but only on activation (Enter and space activates). Then moving the focus would be a side-effect of showing a node. I do like the current behavior though since it's easy to quickly browse the contents of the nodes to see if you got the right one.