GNOME Bugzilla – Bug 320177
Navigate lists by repeated presses of first letter, rather than completion
Last modified: 2006-04-19 14:50:38 UTC
I would like to see the entire gtk+ widget set upgraded to offer improved "keyboardability". Specifically where there are lists, combo boxes or listview controls (in other words any control that displays a series of items from which you can select one or more items) I would like the ability to select items by pressing the keyboard key that corresponds to the first letter of an item name (apologies if these are not the correct widget names but I'm a VB.Net programmer by trade :) The behaviour I would like to see is that in such widgets the "focus" would cycle round each of the matching items in turn. e.g. A widget is displaying twelve items two of which have names that start with "k" and one of which has a name that starts with "K". When the user repeatedly presses the "k" key on the keyboard the focus in the widget should move between these three items cyclically (so when the last item is selected the focus returns to the first item again) Including this functionality in the widget set would mean that such functionality is already built in to any applications that use the widget. This would save developers having to create it themselves (or not create it as seems to be the case in far too many Gnome apps) Personally I am not a mouse user (unless the application forces me to use one) and the lack of this particular feature in Gnome is the major obstacle to my full time use of Linux. Or maybe I'm just used too used to VB and VB.Net where the functionality is built in to the widgets so all your apps come with such good keyboard support "out of the box". And should it be of use I've attached a very simple Windows forms application which I wrote in VB.Net and which demonstrates exactly the behaviour I would like to see (n.b. as I said the actual behaviour is built in to the Windows widget set so I had to artificially produce the behaviour by writing the code in a textbox's keypress event. If this were a real widget the functionality would obviously be in the listview controls keypress event) Other information:
Created attachment 54047 [details] Demonstration code (sadly it's VB.Net but is fairly small and readable by anyone who groks C#) Apologies for not writing this in mono but it's currently somewhat screwed up on my Linux box :)
I don't think we will do this, might as well close the bug. Note that GTK+ already has very adaequate keynav support with mnemonics and typeahead search in treeviews.
Sorry but the keyboard support in GTK+ is most certainly *not* adequate. When compared to using Windows/KDE etc. etc. I consider the keyboard to be very, very poor and, quite frankly, second rate. The specific example which made me raise this issue is that when using Nautilus the keyboard navigation is quite simply pathetic. i.e. when you have several files in a directory whose name starts with "P", pressing the "P" key on the keyboard moves the focus to the first item whose name starts with "P". Pressing the "P" key again does *NOTHING* (Or maybe it once again selects the first item whose name starts with "P" ?). Similarly pressing the "D" key will take you to the first item whose name starts with "D". Pressing it again does nothing. In every other GUI based file manager that I have ever used, on every platform I have ever used, the behaviour is that repeatedly pressing a key will cycle the "focus" through the items who name starts with the letter you are pressing. As a "non mouse" user (i.e. I will only use a mouse where there is no alternative) this is my preferred method for finding files in a directory. The lack of support for this functionality in GNOME is a major usability issue and makes Nautilus absolutely unusable for me. I am therefore currently using Konqueror as my file manager on my Ubuntu desktop (GNOME based) So... assuming that Nautilus uses a GTK+ control to display the items in the current directory then adding this functionality to the widget itself means that this USEFUL, CONSISTENT, almost INDUSTRY STANDARD, behaviour would be available to all apps using the widget. As repeated pressing of a keyboard key currently does nothing it's not even an issue that this functionality would break exising functionality. So sorry but your glib assertion that GTK+ already has adequate keynav support is annoying, condescending and incorrect.
The assumption that the nautilus main control is a standard GTK+ widget is unwarrented, so making assumptions about the toolkit based on experiments with it is not a good idea. That being said, the nautilus behavior here is much like the behavior in the standard GTK+ lists ... if O want to go to a file named 'apple' I type 'ap' and if I want to go to a file named 'aardvark' I type 'aa;' this makes a whole lot more sense than typeing 'a' unmpteen million times and hoping I eventually end up where I want. This behavior is actually becoming more common ... you'll find it in, for example, the keynav for dropdowns in firefox. In any case, as Matthias, we are unlikely to make a change here, however much GTK+ offends your personal taste. (Retitled to something descriptive)
*** Bug 317640 has been marked as a duplicate of this bug. ***
As far as I can tell, that other bug is about changing the keyboard navigation in various vague ways. This is about adding extending the current completion keynav, without changing the current behaviour. Fair enough, if you don't want it, but some reason would be nice.
Sorry, that comment is for the other bug.