How do you even file issues about this sort of thing? The component-based GNOME bugzilla doesn’t lend well to general stuff like this.

If I were to redesign how keyboard navigation works, I would choose 2 or 3 levels of navigation (between sections, widgets, and items), and I would add a key to the keyboard that would only be used for navigation purposes.

But alas, we need to fix one issue at a time

Drop-down lists capture up and down (and since changes in GNOME are applied on the fly, getting caught in one by accident annoys me to no end). Textboxes don’t capture up and down but do capture left and right; moving up and down moves you to ANOTHER focus object!

There is no way of knowing if an object (child or top-level, whatever) will capture arrow key input or not. You’ve seen this with Banshee’s toolbar.

So yes, I would prefer tab-only object navigation, with arrow-key navigation reserved only for special fields and objects (listviews mainly).

Arrow-key navigation should not be an ambiguous “sometimes moves you between fields, sometimes it doesn’t”. And you shouldn’t have to patch your application to make up for GTK’s lame navigation.

Truly? I never dreamed of tabbing through a toolbar on Windows. I love keyboard access, but I always figured that toolbar key navigation was just broken beyond repair, whether it was Office or Firefox. (Although recently I did notice that Office 2007 has quite pleasurable keyboard accessibility).

So that does make sense, but unlike me, you seem to consider every child item in a listbox, for example, as a separate object.

I do not. Lists of items, to me, are inherently different from a “bar of buttons”. It’s a list. The object is the list. I should be able to move through it with natural (up/down/page-up/etc) navigation. I admit subjectivity.

I also feel that natural arrow-key navigation on a toolbar is untuitive; I just never expected it to work, and still found it awkward under GNOME (warranted in the cases of inconsistency where it still doesn’t work – current Banshee an example).

And what REALLY bugs me:

Not that GNOME’s “arrow” navigation of an object doesn’t work; but GNOME inconsistently allows arrow navigation to jump across objects!

There is nothing more bothersome than navigation a good toolbar (ex, Rhythmbox), pressing “down” one too many times, and then ending up in the source list, where up/down changes my view and does all sorts of stuff accidentally I then need to adjust. Why would the same key to navigate groups items irreversibly change my focused object? Now I can’t navigate back the same way and must use shift-tab.

I’m fine with the idea of tab through groups, arrows through sub-items, sure. I have different ideas of what an object group is (lists, not toolbars), but I don’t mind that. I just wish it worked consistently.

Coincidentally there is a bug already filed for Last.fm’s TileView that showcases the issue, every item is focusable through tab, and it takes a long time to cycle through them and get to the next major Banshee component.

In the toolbar case, you might be right. It is counterintuitive to use arrows when keyboarding through those widgets, in my opinion. It is probably that way because Windows users have grown to expect it.

If tab (and ctrl-tab in textboxes) rotated between objects, you wouldn’t have to worry about inconsistent use of left/right/up/down arrow keys.