GNOME Bugzilla – Bug 784635
Wrong key bindings given for GtkTreeView
Last modified: 2017-09-13 04:37:11 UTC
It seems to be impossible to navigate into children using the keyboard (unless the container is already opened). If one presses +/- instead of opening/closing the container the search will be started. I have only seen this in the inspector so far, but it is a rather odd behaviour.
Doesn't Shift+left/right work to collapse/expand the currently focussed node?
trick question: Yes, they do. :P (In reply to Benjamin Berg from comment #0) > I have only seen this in the inspector so far, but it is a rather odd > behaviour. In GNOME it's pretty expected that if an application has a search feature, almost any key pressed without a modifier will immediately start searching. The Inspector is just following suit. Also, Shift+left/right is built into TreeView, so that's equally standard throughout GNOME apps using it, although it doesn't seem to be particularly well documented. Is it common in GNOME apps for +/- to expand or collapse treeviews like this? I just checked Evolution and it supports this, but I can't think of any others off the top of my head - plus, it has a more traditional GUI model than the modern GNOME one (I wonder what using a Nautilus-style email client would be like... :)
Hah! I have never used or even knew about Shift+left/right! The +/- seems to work almost everywhere I tried, this includes even treeviews that will do type-ahead search (evolution folders, gtk3-demo, …). Anyway if Shift+left/right is universally available, then I guess this can be closed as NOTABUG. Though I should open a documentation bug then as that looks wrong either way. The GNOME documentation doesn't even contain +/-. But it does tell you to use Left/Right arrow keys: """ Move selection between items in a single control, or among a set of related controls. Use the arrow keys to focus buttons in a toolbar, select items in a list or icon view, or select a radio button from a group. In a tree view, use the left and right arrow keys to collapse and expand items with children. """
It's hard to decide what should be done, and whether it should be done in GTK+ or the GNOME docs overall... + and - ARE usable for expanding/collapsing rows, iff they're not already consumed by a parent widget, as they are for the search in Inspector and many other modern GNOME apps... so maybe the GNOME docs should pick a better key combo to mention. GTK+ then adds a pile of other default bindings for the expand-collapse-cursor-row keybinding signal, presumably to ensure there's a fighting chance that some of them will make it through. I'm not sure that documenting them all is feasible! That said, of the many keybinding signals in GtkTreeView, only move-cursor has a documentation comment... so, probably, we should patch that to describe all the others, and provide at least an overview of which shortcuts are likely to work. i.e. 'if + and - don't work, try holding every available modifier and mashing the cursor keys', afaict :)
gtk+ => gnome-user-docs (In reply to Benjamin Berg from comment #3) > The GNOME documentation doesn't even contain +/-. But it does tell you to > use Left/Right arrow keys: > > """ > Move selection between items in a single control, or among a set of related > controls. Use the arrow keys to focus buttons in a toolbar, select items in > a list or icon view, or select a radio button from a group. > In a tree view, use the left and right arrow keys to collapse and expand > items with children. > """ That's simply wrong: unmodified cursor keys in a treeview are used to move the cursor, never to expand/collapse. I can't git clone right now, but this should be something like In a tree view, to collapse or expand an item, thus showing or hiding its children, use the shortcuts + or Shift+Right to expand, and - or Shift+Left to collapse. Then I've not checked the context of the quoted section, but chances are this info should then be moved to the summary of other key groups
(In reply to Daniel Boles from comment #5) > gtk+ => gnome-user-docs Please clarify what exactly is wanted in some docs (which ones?), and where.
The document in question is ./gnome-help/C/keyboard-nav.page in the gnome-user-doc repository. It probably needs a bit follow up changes as the paragraph I quoted above is from the "Arrow keys" table row and there are also rows for "Ctrl+Arrow keys" and "Shift+Arrow keys" which mention selection changing.
Created attachment 358328 [details] [review] keyboard-nav: Fix keys to expand/collapse TreeView I can't currently test how this looks, so maybe using keyseqs for arrow keys isn't a good idea.
This assumes the chosen pair of shortcuts work in most places, whereas e.g. +/- are likely to get blocked by aggressive instant searching in lots of modern GNOME apps, so they didn't seem worth mentioning - and may require a new section anyway. (In reply to Benjamin Berg from comment #7) > It probably needs a bit follow up changes as the paragraph I quoted above is > from the "Arrow keys" table row and there are also rows for "Ctrl+Arrow > keys" and "Shift+Arrow keys" which mention selection changing. I haven't looked into whether tree views are in any way ambiguous here, but presumably not; a widget key binding can't have more than one role.
Review of attachment 358328 [details] [review]: Committed as 6441f5fc5d9eb45552a0ba2b94e19dfe7d13ae84 as part of the stable release. Thank you!