GNOME Bugzilla – Bug 105895
Please add common keybindings for the TreeView
Last modified: 2018-04-15 00:02:11 UTC
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81790 told me this is an issue with GTK's tree-bindings. On trees in most applications on other operating systems, space will expand or collapse a tree and enter will choose the selected element. Your keybindings of "+" and "-" are a bit abnormal and I thought you couldn't navigate the tree without a mouse.
One issue here is that in GNOME, Space is the "do it" shortcut, so focusing a treeview item and pressing Space should do the same as double-clicking that item. For those items where double-clicking would otherwise do nothing, expanding/collapsing seems like a reasonable default, however.
> For those items where double-clicking would otherwise do nothing, > expanding/collapsing seems like a reasonable default, however. I think this would make things inconsistent and confuse users. I don't think there is much to do here ...
It confused me having it "+" and "-" because its inconsistant with any other method I have seen (Win32, Mozilla, etc). In Mozilla and Win32 control panel, you use right arrow to expand and enter to select... I forget where I saw space, but the arrow keys seem to be the standard.
The arrow keys are already being used in GtkTreeView to move the focus rectangle over the horizontal axis.
Marking AP3 to reflect a11y team's assessment of a11y impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Discovered we have shift + arrow bindings for expanding/collapsing. > For those items where double-clicking would otherwise do nothing, > expanding/collapsing seems like a reasonable default, however. I am not sure if we can even implement that 100% right. We can check if any signal handler has been connected to ::row_activated, and then decide what to do. But I am not sure how that works with widgets derived from GtkTreeView (since they might have overriden ::row_activated, etc, etc). (Plus I'm still against it since it might confuse people). I propose to close this bug as NOTABUG or WONTFIX.
Does using the right and left arrows alone expand the list? If you look at the treeview on Windows, right and left arrows (without shift) and double-click expand a menu. + and - do nothing. + and - do nothing on Mozilla Preferences and Mozilla's tree view acts exactly the same way as Windows. + and - or shift + and shift - are not GUI behavior people are accustomed to and people moving to GTK from other systems will have no clue what to do. I thought you were trying to make it user friendly for people coming from a Windows or Mac system? Please do whatever is necessary to fix this, even if it can't be done for a year or two. Space is actually not necessary, since Windows or Mozilla XUL trees don't accept it (I just realized), but handling: Double click Left Arrow (without shift) Right Arrow (without shift) is a must for what people would expect moving from a Windows system. >One issue here is that in GNOME, Space is the "do it" shortcut, so >focusing a treeview item and pressing Space should do the same as >double-clicking that item. And double clicking a + item in a treeview normally (as far as I've ever seen it on other systems) expands the list, so why isn't gtk doing the same?
> Does using the right and left arrows alone expand the list? No, it doesn't. My comment from May 27 states that the left and right arrow keys are already used to move the key focus rectangle horizontally. > I thought you were trying to make it user friendly for people coming > from a Windows or Mac system? We are not trying to clone Windows. We are creating an alternative toolkit (and GNOME an alternative desktop environment). Therein usability/consistency as defined by GTK+/GNOME comes first, after that, if possible, we can add convenience bindings generally used on other platforms. > Please do whatever is necessary to fix this, even if it can't be > done for a year or two. We *cannot* free the arrow keys from the key focus rect. bindings which they have. TreeView *needs* this to support focussing single cells individually with the keyboard. > And double clicking a + item in a treeview normally (as far as I've > ever seen it on other systems) expands the list, so why isn't gtk > doing the same? Back in the 1.3 days GtkTreeView did expand/collapse rows by double clicking on parent nodes. But when we discovered that we overloaded double click by having it activate rows and expand/collapse parent rows, we decided to drop the ability to expand/collapse parent rows by double clicking.
>But when we discovered that we overloaded >double click by having it activate rows and expand/collapse parent >rows, we decided to drop the ability to expand/collapse parent rows by >double clicking. Why? Its not only logical to use the same bindings, but its also easier for the user. Expand a row by double-clicking, then activate the row that's a child of that with the same action. To give a parallel, you wouldn't make it so you right click to open a menu in a program, then left click to choose a menu element. You say doing this would confuse users, but I'm a users and having a different key or mouse action for similiar functions confuses me. I don't like remembering 8 million different ways to do the same thing, all of which incompatible with each other. Single-click should select the item, and double click should expand it or activate it. Expansion of a parent node would then seem to be a form of activation to the user (no matter if you differentiate it). >The arrow keys are already being used in GtkTreeView to move the >focus rectangle over the horizontal axis. What does this mean (for people that don't develop for Gtk)?
> Single-click should select the item, and double click should expand it > or activate it. Expansion of a parent node would then seem to be a > form of activation to the user (no matter if you differentiate it). Who will choose what double click on a parent node would do? There can only be one *fixed* action. > >The arrow keys are already being used in GtkTreeView to move the > >focus rectangle over the horizontal axis. > What does this mean (for people that don't develop for Gtk)? The focus rect is a keynav cursor. It appears as a dotted rectangle around rows. In some cases (mostly in editable treeviews) you can move this cursor to the left and right with the left and right arrows keys.
> There can only be one *fixed* action. Its your code, can't that be changed? Parent nodes obviously can only be expanded, while child nodes can obviously not be expanded and only activated. Therefore, the activation event for nodes that have children would be simply to be redundant for expansion. >The focus rect is a keynav cursor. It appears as a dotted rectangle >around rows. In some cases (mostly in editable treeviews) you can move >this cursor to the left and right with the left and right arrows keys. Is there a working example of this so I can see what you mean?
The code can be changed without problems. As I said before we've had a double action on double click for a while back in the 1.3 series. That there can only be one action per binding is just a design rule. The problem is if you can reliably determine if the user/programmer wants an activation or expand/collapse event for his parent node. Examples for the keynav cursor: all treeview demos in gtk-demo.
In the case of why I filed this bug -- the "redhat-config-xfree86 doesn't allow keyboard expansion of tree list without a mouse.", there wouldn't be a need to have parents do anything but expand and show its children. I guess you are talking in a more general sense, so maybe there are cases where you'd need a parent node to be activated. So we have at least determined that when it does nothing, it could default to expand/contract. Of course, this would be inconsistent. I looked at what Microsoft did in the control panel, and although I'm not a fan of M$, I know they have poured a lot of money into UE research. From what I found is this: In the control panel, they set up the list in a way that parent nodes expanded on double-click, but child nodes brought up the properties window (were activated). To bring up the properties menu on the parent nodes, you had to right click and choose properties. I think this goes to show that you could allow tree-view expanding of parents with no regular action set, and then just put a stipulation in that its the responsibility of the person implementing tree-view to make sure that there is consistency between parent nodes. The other choice would be to make it so parent nodes always expanded by double click and you had to right click (or equivalent) to do their action, which would show up in a menu.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
This feature is rather annoying. It makes Nautilus, for example, a complete pain to use. So much so that people raise bugs like Bug #321647 saying that there is "No way to expand directory with keyboard". Can we please fix these keyboard controls on GtkTreeView? Unmodified Arrows scrolling the view while Shift+Arrows are mapped to expand and contract is such a waste, it should be the other way round.
Created attachment 62335 [details] [review] gtktreeview.c keyboard navigation changes Here's a patch that does what I wanted, taken against Ubuntu 5.10's libgtk+ (gtk+2.0 2.8.6-0ubuntu2.1) It changes the navigation keys for treeviews to these: Left/right arrows contract/expand Left on a node w/o children goes up a level Right on a node w.children goes down a level Expand-all-child behaviour only happens with Shift-right Ctrl-left/right used for the previous left/right behaviour (change focus)
As I said earlier: Comment #4 from Kristian Rietveld (gtk+ developer, points: 18) 2003-05-27 17:22 UTC [reply] The arrow keys are already being used in GtkTreeView to move the focus rectangle over the horizontal axis. I am not taking any patch that changes the behaviour of the left/right arrow keys.
It was also said in Comment #9 that "usability/consistency as defined by GTK+/GNOME comes first" According to the HIG http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html "* Do not assign awkward reaches to frequently performed keyboard operations. Some people may only be able to use one hand on the keyboard, so shortcuts that can be easily used with one hand are preferable for common operations." "* Do not require repetitive use of simultaneous keypresses." In order to navigate a tree, one can use use the up and down arrows, but to expand a node one has to reach for the shift key as well, or the equally awkward +- keys. Which is done more, expanding/collapsing nodes or traversing focus to the left or right? Out of some common programs that use the treeview in Gnome - Nautilus, GnomeBaker, Rhythmbox, Evolution, Glade's Widget Tree and Liferea - only Rhythmbox has cells that make use of the current left/right focus change behaviour, in a one-level-deep tree (no expandable nodes) that is used to show the track list. This indicates that the current shift+left/right for expanding/collapsing nodes goes against the usability guidelines as defined by GTK+/Gnome. I haven't forgotten the guidelines that state "any text that can be selected with the mouse can also be selected with the keyboard" and "ensure every control on menus and in dialogs are directly focusable using access keys or shortcut keys", but these are secondary, less used features of the treeview and would not be such a burden if they had marginally harder to use keyboard shortcuts.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
*** Bug 350104 has been marked as a duplicate of this bug. ***
I want to get this resolved soon now. Calum, what's your take on this issue? Matthias, and yours? Can we make such changes in the 2.x series? (I would say change, because people can change it with their keytheme anyway). (In reply to comment #18) > Left/right arrows contract/expand > Left on a node w/o children goes up a level > Right on a node w.children goes down a level I am not really sure whether these two make sense. > Expand-all-child behaviour only happens with Shift-right > Ctrl-left/right used for the previous left/right behaviour (change focus)
(In reply to comment #17) > This feature is rather annoying. It makes Nautilus, for example, a complete > pain to use. So much so that people raise bugs like Bug #321647 saying that > there is "No way to expand directory with keyboard". Can we please fix these > keyboard controls on GtkTreeView? Unmodified Arrows scrolling the view while > Shift+Arrows are mapped to expand and contract is such a waste, it should be > the other way round. Recently I downloaded Gimp for Windows which required installation of GTK for Windows. It was surprising when I first noticed that GTK's tree views cannot be navigated easily using keyboard. At least until I've found "new" shortcuts ("+" and "-" keys, Shift+Arrows), this bug and bug #88314. For a long time I was thinking that this issue was a Linux-only thing, but now I've found the real source of this problem. Normal arrows SHOULD indeed expand and collapse nodes. Shift+Arrow, Ctrl+Arrow or Alt+Arrow could be used for scrolling, both horizontally and vertically, leaving normal arrows for navigating contents of the tree only. Otherwise the behaviour is inconsistent with overall look and feel. Please modify GTK's default behaviour or at least give the option to change it for the end user. It would also make my GNOME experience a lot better, since I'm used to navigate the expandable tree using four closely located keys on the keyboard. That is arrow keys. It's easier from usability POV and consistency with other desktop environments (and that's not only Windows). -- Registered Linux user #390131 (http://counter.li.org)
I've dig a bit deeper and found bug #272342. Looks like Evolution already uses Left and Right arrows to collapse and expand mail threads, although it seems to be a little buggy at the moment. Putting more consistency throughout the whole GNOME desktop would be a big bonus IMHO. Since there's new GNOME release ahead it may be a bit late for it to include the change in TreeView's key bindings. But it still would be a plus to have. [ sorry for spamming yor mailboxes twice in a row... it's important for me personally, so I'm trying my best to convince developers to help GTK users, including me of course :) ]
*** Bug 88314 has been marked as a duplicate of this bug. ***
I've changed cvs HEAD to expand/collapse branches with right/left, the focus cursor could already be moved with ctrl+left/right and that will remain the same. Note that you can use BackSpace to go up a level from a node (I was told this keybinding was taken from Windows). 2006-10-30 Kristian Rietveld <kris@gtk.org> * gtk/gtktreeview.c (gtk_tree_view_class_init): change left/right keybindings to collapse/expand rows instead of moving the focus cursor. (#105895, Brian Bober and others).
Are those keybinding only active if you use expanders at all? I use flat trees as lists and I need the keys for efficient manipulation of cell data. So is backspace free if I have no expander tree?
Commit has been reverted in r18768. Bugs streamed in from people complaining that left/right didnt move their cursors anymore. People are very divided on this issue and in a .12 release we felt it was better to keep the old behavior rather than changing behavior which has been there since 1.3.x. Since GtkTreeView is being used as both a table and tree, we are going to need a more sophisticated plan to fix this. We could base the decision on factors like: * Is the model a list or tree? * Are there any activatable cells in the column configuration? Etc.
*** Bug 497491 has been marked as a duplicate of this bug. ***
How about space to expand/collapse the tree? I know it was said that both space and enter is used to activate the current item... Maybe that can be changed? If right and left arrow keys cannot be used, then space is the best alternative.
Wouldn't it at least make sense to make ARROW-Keys collapse/expand in a TreeView with only one column because there's no horizontal cell-focusing possible at all.
*** Bug 581429 has been marked as a duplicate of this bug. ***
I created bug 581429, which is now a dupe of this one, so i will comment here: In nautilus' list view, the left/right arrow keys do NOTHING. They are entirely unused. They should really do something useful, as these keys are very convenient to use.
I want to applaud all the heroic efforts over the years by users and developers to raise awareness of the usability issue with the Gnome tree control. The default keybindings, in the opinion of this user migrating from another O/S, hurts productivity. I believe tree view needs to have better arrow key support. It would be superb if the default behaviors and keybindings worked like other operating systems as it would ease the pain of user migration. But in my case, I go beyond simple personal preference as to why I have chosen to contribute my $0.02 to this enhancement request... The current situation with the space bar and ctrl+left/right is muddled depending on the application. I've seen some tree LEVELs in trees in Eclipse, for instance, that had for some reason grabbed the space bar (Class type inspector, I think.) This allowed me to expand/collapse the first level of the tree, but then space no longer worked on deeper levels - and I had to reach for the mouse to continue expanding/collapsing. So I think my main problem, and reason for adding this comment, isn't simply that "Gnome wasn't developed as a replacement for Windows Shell" but that the current implementation with the space bar doesn't work 100% of the time. For good or ill, I have trained myself to use space with Eclipse on Gnome, that is now in my muscle memory. But when it doesn't work 100% of the time, someone has failed either at the design or the development stage. Someone must be held to account. I must be compensated for lost time! Now, you can argue the Eclipse app should not have bound to space for that particular tree level. After all, it's not Gnome's fault some app mistakenly bound to space at an odd time, in of all places, a particular tree control LEVEL, for Pete's sakes! But then I would argue back, soooo ... space is a pretty important, mostly non-control oriented key on the keyboard. Well, yes, it IS used for control on radios and checkboxes for select/toggle, you got me there. But did you REALLY get me there? See, I contend tree controls and even items in the tree are different from radio and checkbox because they are not one-dimensional elements. Tree levels are not booleans! There is surely a PART of each tree control level that is a boolean: the twisty arrow. I suppose if you could navigate somehow with the keyboard to focus just on the twisty arrow itself, then you could argue the boolean nature of the twisty and space would be an appropriate as a toggle on it. But you can't do that, you navigate to the entire tree level object, which might itself contain an edit field or other nested controls that might themselves take keyboard bindings (ok, granted, an odd way to use tree) and might find the space bar key otherwise useful: conflict! I'm just arguing that the tree control level is too complex to be given the space bar binding, it doesn't itself represent the simple boolean. Rather, I would argue that tree levels are "navigated" rather than selected/deselected and thus should have navigation-type key bindings. Yes, I have considered that ctrl+left and ctrl+right could be the "navigational" key bindings I desire. But that doesn't change that the space bar is an inappropriate assumption and thus, binding. There, I finally said it; I tried to be diplomatic about calling the current convention "wrong", and hopefully "inappropriate assumption" has softened the blow. :) I am curious though, would it be technically possible with GTK to double bind the arrow keys without any meta just to bring us in line with other operating systems? For example, the highlighted row of the tree view item always has "first dibs" on the right/left arrow key events for expand/collapse and then passes the event on to the containing scrolling pane if the event is not consumed. Is it that keyboard binding events don't flow in that direction on GTK from contained to container? That's not to say there is any value in copying the conventions of a competing O/S. Nope, I did not mean to insinuate that that is exactly what I am thinking, so please find some other rationale like booleans and inapproprate assumptions. :D Honestly and without being facetious, I do think left/right arrow support on the tree control would be good for humanity. It really is important. I have this hopeless feeling that productivity is slowly slipping away from me on all computing and UI fronts - too many fancy designers throwing in fluff that seemingly always requires the hand moving to the mouse. I'd just like to have rock-solid keyboard support throughout all of my apps where the default widgets are concerned and, if I'm lucky, reclaim a bit of my future time. Thanks. Love Linux, and I like Gnome most of all the shells, DaveW
> Tom Schindl 2009-03-15 16:29:37 UTC > Wouldn't it at least make sense to make ARROW-Keys collapse/expand in a > TreeView with only one column because there's no horizontal cell-focusing > possible at all. Or to make the UX the same, keep focusing right on the right arrow, but when on the last element, open the subtree. Similarly with the left - left key on the left most element could close the subtree. This would work very naturally on one column trees, and should still be more convenient on multi-column ones.. Although not sure if two right keys is any better than a shift-right.. -- I'm not quite sure why I didn't notice this for so long (maybe I didn't use any apps using tree views?).. but when I found this a few weeks ago I cannot use tree views w/o thinking about it.
(In reply to Jakob Unterwurzacher from comment #34) > In nautilus' list view, the left/right arrow keys do NOTHING. They are > entirely unused. > They should really do something useful, as these keys are very convenient to > use. That shortcoming in Nautilus seems to have been fixed at some point in the 7 years since that comment was posted. GNOME Files (formerly called Nautilus) now has support for using the left-, right-, up-, and down-arrows to navigate and to expand and contract subtrees in the list view, as long as the "Navigate folders in a tree" option is ticked in the preferences. Yay! This gives me hope that *this* bug (Bug 105895) might also become fixed eventually, if it hasn't been fixed already. Please could a GNOME developer comment with an update if he/she/they knows of any progress on that front? Thanks!
A user on the Ubuntu bug tracker has submitted a patch that appears to fix this bug: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1020756 Please can the patch be merged into GTK? In the meantime, there are some partial workarounds here, involving creating a ~/.gtkrc-2.0 file if it doesn't already exist, and adding appropriate key-bindings: http://stackoverflow.com/q/4747264 . It is only a partial workaround because the correct behaviour of the arrow keys ought to vary depending upon the status of the highlighted line in the tree view, as described in the Ubuntu bug report above, and as equivalently described here: https://msdn.microsoft.com/en-us/library/aa443492%28v=vs.60%29.aspx and here: https://books.google.co.uk/books?id=5_UoYcmkvncC&lpg=PA81&ots=4m2g1nHhxl&dq=tree%20expand%20collapse%20right%20left%20arrow%20keys&pg=PA81#v=onepage&q&f=false
In case it helps, here is a personal account of why the present behaviour is flawed, based on experiencing it in GnuCash. Quoting the GnuCash wiki[1]: > To expand a place holder account in the tree view of the main window > account page, use Tab to select the place holder account, then press > Shift + right-arrow (the arrow key on pc-keyboard), to collapse the tree > view of any place holder account press shift + left-arrow This is thoroughly unergonomic for me, because: - It is different to every other tree view I am familiar with, across platforms, including the tree view in GNOME Files. - It requires pressing two keys in a "chord" when one key would suffice, potentially leading to "Emacs pinky" or similar RSI issues. - The fact that the right-arrow and left-arrow keys by themselves *do not* appear to do anything in the GnuCash account tree view, is inconsistent with the fact that up-arrow and down-arrow keys by themselves *do* navigate (as they should!) up a line or down a line in the GnuCash account tree view. So, please help users of GTK-based software to be more productive, happier, and to have healthier tendons: implement the patch posted on the Ubuntu bug tracker, mentioned above! Thanks :) [1] https://wiki.gnucash.org/wiki/Keyboard_Shortcuts
Bounty posted: https://www.bountysource.com/issues/3554615-please-add-common-keybindings-for-the-treeview Anyone reading this, please consider adding to the bounty if you'd like to see this fixed. Hopefully the bounty will motivate someone to make the fix and claim the reward, either for themselves or as a donation to the Gnome Foundation.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new