GNOME Bugzilla – Bug 512175
In Search window, there is no convenient way to get from search field to results with keyboard
Last modified: 2013-01-19 23:09:18 UTC
In 0.8.2, if I pull up the "Search All Notes" window, and type in a search term, there should be a convenient way to move focus between the search field to the result list. At the moment, the key sequence to go from search field to the first result is: Tab-Tab-Tab-Tab-Tab-DownArrow. Ideally, pressing down arrow in the search field should move focus to the first result, and pressing up arrow on the first result should move focus to the search field. (This is how the Deskbar search window works.) At the moment, pressing down-arrow in the search field causes Tomboy to clobber your current search term with whatever search term you used last, and pressing up-arrow at the top of the results list just beeps at me. It's a nice beep, but the flexible Gnome desktop exposes beep-generation functionality through sufficient other UI that I would not regret losing this instance. Other information:
Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".
I agree. I love using the keyboard and this shouldn't be a big issue. I'll try to tackle this for the next cycle.
*** Bug 572229 has been marked as a duplicate of this bug. ***
Created attachment 186466 [details] [review] Patch that allows the Return key to move focus to the Notes Tree This patch makes it so that you can hit the Return key and move to the notes tree. A second strike of the return key will open the first note in the list. You can also hit the arrow key as the second strike instead of the return key. I was thinking of changing it so that if there was only one match it would open the note, but that seemed a little much :) Thoughts? I don't know if this is the best way of doing this, but it seemed to work.
Navigation should be with the tab key instead of the return key.
I think you can setup a tab cycle group for a window.
Yes, but the problem with that is that it's a combo box with a drop down. While I never use the history, I would think that it would be the next logical tab key. Now I suppose that we could allow the Note TreeView to be the second tab sequence. Which would be a lot better than what it is now. I was thinking that the Return Key is unused and would be a quick way to get to the Note View.
Okay, I get your reasoning. Also, I hadn't considered the drop down menu. I would expect it to work like one of two scenarios: If the drop-down is exposed, tab cycles to the dropdown, then to the note list, then to notebooks, and back to the search box. Possibly include the menu? I don't know about that. Otherwise: If the drop-down is exposed, make it accessible with the arrow keys and keep the drop-down menu out of the tab cycle. Regardless, tab tends to be the de facto "move through visual interactive visual elements" key.
I can't seem to make it work using the chain focus. It appears to me that the chain focus doesn't have an effect if I set it to the three. If I set it to the vbox then tab doesn't go anywhere. Running a little GTK test it seams that there are limitations to what containers you can cross when specifying this..
Closest I can get is with this code which takes you from search, to notebooks to notes to search. // Set Tab focus sequence Gtk.Widget[] focus = new Gtk.Widget[2]; focus[0] = find_combo; focus[1] = tree; hbox.FocusChain = focus;
That's actually _more_ in conformance with the GNOME HIG than what I originally proposed, as the focus moves from left to right and top to bottom... As in the order is top, left right for focus movements. We just want to ensure that the primary method of navigation is the tab key. I sort of feel like I'm being obtuse about this, but I think if ever there was something to be obtuse about, it's GUI consistency across a platform.
Yeah, I understand. :) So I was thinking more about this and maybe I need to configure the focus chaining per container...I can make it work if I don't do any custom chaining, but as soon as I try to write a custom chain it gets weird. I am sorta able to duplicate this on a GTK test..so I will keep hacking on it :-)
Created attachment 186637 [details] [review] Set FocusChain This patch sets the FocusChain. The focus sequence moves from Search, to Notes, to Notebooks to Search. Yes - this patch does not move the sequence to the "Clear Search" button, but I beg that this be acceptable <G>
Comment on attachment 186637 [details] [review] Set FocusChain I'm commiting this because it's an obvious improvement, but I'll leave the bug open. If no one else has any comments, we'll close it when 1.8 ships.
Aaron, Would you like to close this bug now that 1.8 is out?