Re: on application focus navigation (was: On ctrl-tab)

[Jud Craft <craftjml gmail com>]

[I apologize, this should have gone to the list.  I really have to
watch the Reply-to-All button in Gmail.]

On Wed, Nov 25, 2009 at 1:51 PM, Behdad Esfahbod wrote:
>> You can tab into a ListView, but not shift-tab (only
>> into the headers), and not being able to tab through toolbar buttons
>
> File bug?

One step ahead.  https://bugzilla.gnome.org/show_bug.cgi?id=600168.


>> (but you can ctrl-tab -- until you hit a non-button widget!  or
>> whatever.  it's extremely difficult to keep track) is a nightmare.
>
> Either file bugs, or if its more fundamental stuff, bring it up here.

The general underlying problem (from what I understand from talking
with one of the Banshee accessibility developers) is that GTK defines
"widget groups", with child elements that you can only access using
ctrl-tab.

But then again, it seems to define child elements that you -can-
access using tab (assuming that the ListView bug I mentioned is
actually a case of headers + listdata being one widget group).

Aside from the very annoying exception of the ListView, I think I
would call this an unfortunate design decision rather than a bug, and
I can't change that nor make GNOME developers design to retool their
GUI for my vagaries.


>
>
>> Panel keyboard navigation (trying to work through the launchers, task
>> buttons, and menus) is another thing entirely, but a little better.
>>
> Agreed.  File bugs?

Wouldn't bother.  Isn't gnome-panel getting phased out?  And the Shell
hasn't began keyboard access work yet.


>> Never mind that sometimes, just pressing an arrow key makes my focus
>> jump from a toolbar to the document!
>
> Yeah, that can be quite handy or annoying depending how you look at it.

Tell me about it.


>> PS.  I have no idea how to file bugs against the interface guidelines
>> themselves -- or even if anyone agrees with me.  Are people really
>> happy with GNOME keyboard focus navigation?
>
> Technically the HIG, but doesn't help that it's unmaintained.  So, perhaps
> we need to address this problem first, that currently there's no way to
> change these things.
>

So, if you don't mind my asking -- where exactly is the canonical
reference for GNOME GUI design?  I assume you mean the GNOME HCI
Guidelines 2.2 are unmaintained?  Or is it just kind of touch-and-go?



>> I'd much rather them fix focus switching to use Tab *exclusively*, and
>
> How would you Tab out of a gedit text area?

Well, you've got me.  My problem isn't necessarily that GNOME uses a
combination to escape from a text-entry field.

I'm actually okay with using tab and ctrl-tab.  But I at least want
one way that is -always active- to move between fields.  GNOME
currently can't do this.

For example.

1.  In the Run Application Box, I can use tab or ctrl-tab equally to
get through every field.  It's lovely.
2.  Open up Gedit.  Try to cycle through every field once.  You can't
use just tab, or just ctrl-tab.  You have to use a combination of
different shortcuts.

It would be cool if you could cycle through every field with a
[modifier]+tab key.  But you can't.  You can get through many fields
with ctrl-tab, but then you get stuck on the toolbar.

For some reason, in the Run Box, ctrl-tab can go through every widget,
but in GEdit it gets stuck in the toolbar group.

It would be ideal if ctrl-tab could, at least, perfectly cycle through
every field on its own.  You could set Sticky Keys on ctrl, and then
dance through an application to your heart's content.


'Tab' is merely a convenient legacy-user shortcut to switch between
fields, and you also need a shortcut that does not conflict with
text-entry.

1.  Ctrl-tab can do this, or it could be anything else.
2.  Ctrl-space (probably conflicts with some of those
Gnome-Do/Launch-bar type programs)
3.  Super-tab (I kinda like this one, since GNOME doesn't let you
reserve super-shortcuts [except GNOME-Do for an odd reason].  So this
one should be safe).


Whatever it is, it needs to be able to cycle through all fields.
Currently GNOME has no such shortcut, although it'd be cool if
ctrl-tab could do it.  Maybe a bug could be filed?

And perhaps later the default "canonical focus shortcut" combo could
be super-tab or somesuch, if people really wanted to retain ctrl-tab
for document switching.