Re: keyboard/focus annoyance after sorting in list view

[Matthew Paul Thomas <mpt myrealbox com>]

Holger Berndt wrote on 06/03/09 11:51:
> 
> On Fri, 06 Mar 2009 10:14:35 +0100 Alexander Larsson wrote:
>...
>>> The way it's implemented makes it difficult for people who *don't*
>>> want to use the keyboard to navigate everything. Why is it that
>>> it's all or nothing? Even Apple provides a switch for this
>>> (basically, on/off - with "off" allowing only certain elements to
>>> be focused by keyboard).
>> 
>> Really? Is this a global switch? How is it decided which elements are
>> allowed to be focused?

To clarify the description John Keller gave (in nautilus-list@): The
default behavior in Mac OS X is that Tab and Shift Tab cycle focus
through a window's list boxes and text fields, and nothing else. (A
folder window's contents counts as a list box in this sense, regardless
of what view it's in.) The system-wide "Full Keyboard Access" setting
changes this so that Tab and Shift Tab cycle focus through all controls,
à la Windows or GTK.

An example of how this would save time in Gnome: You're connecting for
the first time to a wireless network that has a complicated password.
Network Manager's connection dialog opens with the password field
focused by default. You check the "Show password" checkbox (either by
clicking, or by using its access key), then start typing the password.
You don't need to do another click or a Shift Tab to return focus to the
password field, because checking the checkbox didn't cause the password
field to lose focus in the first place.

> I don't know how Apple does it -- but to me, that is an excellent idea!
> Though I don't think this can be automated in a meaningful way, as
> general rules by widget type are not really useful.

It works for the Mac. However, it would be necessary to have a way of
saying "this control counts as a list box or text field" for a custom
control (such as Nautilus's icon view, or Banshee's list view), so that
it could be added to the set of focusable controls alongside any
standard lists and text fields.

> Still, gtk+ could have a global bool switch to build up the focus chain
> of all focusable widgets or just the ones that the developer considers
> "important" for keyboard navigation. Each widget would have a property
> "important_for_keyboard_navigation" that application developers can
> set.

I think leaving it entirely up to application developers would be rather
useless in practice, because there would be no visible distinction
between "important" and "unimportant" items. This in turn would mean
that (a) application developers would often forget to set the attribute
at all, (b) when they did set it they'd often set it inconsistently
between windows and apps, and (c) users would not be able to tell by
looking at a window whether Tab was going to do what they wanted.

>...
>>> But maybe that's the GTK stack. There's also the application level. 
>>> Forgive my ignorance if this already exists, but I think that at
>>> the very least Nautilus could give a keyboard shortcut that gives
>>> focus to the file list frame, no matter where the focus is
>>> elsewhere in the window. The way things are, it requires juggling
>>> the mouse and the keyboard (or counting keystrokes/monitoring the
>>> screen closely when using keyboard only).
>> 
>> This isn't a bad idea. Does any other app have this, and if so what
>> shortcut are they using?
>...

The only keyboard combos of this type that I know of are those for
focusing address and search fields in Web browsers (e.g. Ctrl L, Command
L, Alt D, Shift Command F, Ctrl K).

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/