GNOME Bugzilla – Bug 53580
KEYNAV: GtkTreeView
Last modified: 2011-02-04 16:09:32 UTC
Navigation ---------- In a single-selection tree or list, these keypresses should select the newly-focused item and deselect all others. In a multi-selection tree or list, they should move keyboard focus to the new item, but leave the selection state of all other items unchanged: - Up/down arrow = previous/next row, scrolls list if necessary - PgUp/Dn = top/bottom row, then top/bottom row on prev/next page if presseed again - Home, End = first/last row - Printable character = next row in list starting with that char Additionally, in a single-selection tree, pressing Backspace should select and focus the parent of the currently-focused item. In a multi-selection tree, pressing Backspace focus the parent of the currently-focused item, but not select it or affect the selection state of any other items in the tree. The following keyboard shortcuts should be available in a tree only, and should not affect current focus or selection: - Right arrow or "+" on keypad = expand selected branch - Shift+right arrow or Shift+"+" on keypad = expand selected branch and all its children - Left arrow or "-" on keypad = collapse selected branch - Shift+left arrow or Shift+"-" on keypad = collapse selected branch and all its children Selection --------- In single-selection trees or lists: - Ctrl+Spacebar = toggles selection state of currently-focused item. In multi-selection trees or lists: - Ctrl+A = select all rows (including hidden rows, in a tree) - Spacebar = select currently-focused item, deselect all others - Ctrl+Spacebar = toggle selection state of currently-focused item, doesn't affect selection state of any other items - Shift+spacebar = extend selection from last selected item to this one - Shift+up/down arrow = extend selection up/down one row - Shift+Home/End = extend selection to first/last visible item in list/tree - Shift+PgUp/PgDn = extend selection to top/bottom of current view, then to top/bottom of prev/next page if pressed again [Check http://developer.gnome.org/projects/gap/keyboardnav.html for any later proposals that may not have filtered through to this bug report yet]
How should I handle reordering columns? Currently, you can click on a header and drag it around, but there's no pure keyboard way to do this.
Once the column header has focus (see thread at http://mail.gnome.org/archives/gnome-accessibility-list/2001-May/msg00049.html for a discussion on this), I'd suggest that: - Ctrl+left arrow moves the selected column one position left - Ctrl+right arrow moves the selected column one position right Less important, but perhaps useful: - Ctrl+Home to move selected column to first/leftmost position in list - Ctrl+End to move selected column to last/rightmost position in list In all cases, the column that has just been moved should retain keyboard focus.
*** Bug 50053 has been marked as a duplicate of this bug. ***
*** Bug 56499 has been marked as a duplicate of this bug. ***
Latest keynav suggestions for GtkTreeView now available here (following a discussion on IRC we had weeks ago): http://developer.gnome.org/projects/gap/keynav/gtk_lists.html
Tables and trees should in general have some sort of navigability via keyboard on a 'cell by cell' basis even if the cells are not editable, and this 'focus' should be accompanied by some visual indication of the 'current' cell. This is required for accessibility support, both in order to support the ATK accessibility interfaces, and in order to support functional accessibility for mobility impaired and blind users. This means that some 'focus-like' event, or else some property-change event from which the 'current' cell can be deduced, needs to be a part of the fix for this bug as well.
Can you guys look at the current keynav stuff, and tell me if it's better? Ctrl-A and reordering columns still isn't implemented, but I think the rest has been.
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
I started working on this, hope to get it fixed in time.
Keynav should be a _lot_ better now. Calum, could you please try and file issues you find as seperate bugs? I already filed one issue I still need to look into (page up/down brokenness -- which affects a lot of other treeview keybindings) under #72187.