GNOME Bugzilla – Bug 131226
Unable to select listview files with keyboard
Last modified: 2011-02-04 16:16:11 UTC
In spatial mode, with the List View: This works: Click on Filesystem in the top-level "Computer" window. Press the Down cursor key once, to move out of the treeview column title. Press the Down cursor key again to select the first item in the list. This is a real selection, not just an accessibility focus indication. This also kind of works, but is strange: Click on usr in the top-level FileSystem window Press the Down cursor key once, to move out of the treeview column title. This time, we see a focus indication on the first item. Press the Down cursor key again. This time it selects (a real selection) the 2nd item, instead of the first. Press the Up cursor-key to select the first item. This does not work: Click on /home in the top-level FileSystem window. My PC has only one user, so there is only one folder there - "murrayc". No combination of up or down cursor keys will allow me to select that item. The first down cursor key press moves the focus indicator out of the treeview column title and onto the first item, but is is never really selected. I think I've seen a similar bug report before, but I can't find it now.
Updating status whiteboard to reflect a11y team's assessment of priority.
I am confused by the bug description. Is it that it is not possible to select a file in a directory which contains exactly one item when using view as list?
> Is it that it is not possible to select a file in a directory which > contains exactly one item when using view as list? Yes, I think this might be the one simple reproducable test case.
Or pressing dDownArrow when focus is on the TreeView's column header does not select the first row.
The Treeview is nautilus has GTK_SELECTION_MULTIPLE and this causes the first row not to be selected when focus is moved to the GtkTreeView. It works if selection is not GTK_SELECTION_MULTIPLE.
Created attachment 23894 [details] [review] Proposed patch
*** Bug 120933 has been marked as a duplicate of this bug. ***
Bumping down the AP status a notch, as I guess a user can always use icon view + file properties dialog to achieve the same results as they could in the list view (although that's obviously less convenient).
Bumping down the AP status a notch as I've just found a workaround-- you can select the single item by pressing Ctrl+Space when it's focused. (And also because I guess a user could always use icon view + file properties dialog to achieve the same results as they could in the list view, although that's obviously less convenient.)
Hmm, apologies for the odd double-posting, ignore the penultimate one :)
The reason it works like that is that it was deemed important to be able to tab to a TreeView without altering the selection.
Based on Jonathan's comment is this bug NOTABUG and it is a documentation issue to make sure that the user knows how to select a single row?
I still don't understand why the arrow keys don't allow the first item to be selected (i.e. arrow keys should be grabbed by the treeview, as opposed to TABs) - why would it be bad to allow that? i.e. tab (or arrow) to treeview-list press down (or up) arrow again to move selection or select first item.
*** Bug 134415 has been marked as a duplicate of this bug. ***
Jonathan said that he has no opinion on this issue; therefore I think to make progress we would need a patch that implements Bills proposal: 1) don't change the selection when tabbing into the treeview 2) change the behaviour of arrows to select the current item, if it isn't selected, and otherwise move the selection
I will attach a patch which attempts to implement Bills proposal. The patch does the following: a) When focus in on Column Header, pressing Down arrow key selects the first row in the treeview. Pressing Down arrow key once again selects the next row. This works for a treeview with one or more than one row. b) If treeview had selection (say 3rd row) before focus was moved into Column header, pressing Down arrow key selects the row (3 rd), which had selection before focus was moved out of treeview. c) Behaviour of Tab and other arrow keys is unchanged.
Created attachment 25162 [details] [review] Proposed patch
I'm going to try to get this in for 2.4.0.
I don't like the behavior of that patch. It seems to just add another magic key sequence (down from the toolbar as opposed to C-space) and doesn't really help. As we don't really support navigation of controls through arrow-keys, people won't find it on tabbing in. I'm thinking that a better behavior may be to have it select rows on Up/Down, even if the cursor doesn't move. So if you have a list with one item and multi-selection set, tabbing in would set the cursor on that item, but not select it. Pressing up/down would select that row (which is kind of the case w/ two items) and not move focus (like now). Hitting page up/page down will also select the row (which it currently does), as will Ctrl-Space. Does this make sense Calum? Is it good enough?
I think so, although it took me a while to get my head around it :) Would it be fair to say that we really just want a multi-selection list with a single item to behave like a single-selection list, or is it not quite that simple...?
Created attachment 28286 [details] [review] New patch Patch which attempts to implement Jonathan's suggestion.
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.
what's wrong with the patch? This bug has had its milestone changed twice since a patch implementing Jonathan's suggestion was posted, and it's marked as serious for accessibility.
Sorry Bill; I haven't had a chance to go through my bugs recently. Thanks for the ping. The new behavior feels pretty good. Padraig, can you commit to both HEAD and 2.4? Also Calum, you might be right that handling multi-selection w/ one item as single-selection, but the number of differences is small, and encoding it as such might be more work than its worth.
Fix committed to HEAD on behalf of Padraig, who is away.
Fix committed to gtk-2-4 branch also.
Thanks Jonathan!
*** Bug 149471 has been marked as a duplicate of this bug. ***
*** Bug 145331 has been marked as a duplicate of this bug. ***
*** Bug 152665 has been marked as a duplicate of this bug. ***