Re: keyboard/focus annoyance after sorting in list view

[Matthew Paul Thomas <mpt myrealbox com>]

Holger Berndt wrote on 09/03/09 11:23:
>...
>>> 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
> 
> That's a matter of default values. Say an
> "important_for_keyboard_navigation" widget flag gets introduced. Then
> your proposal is in effect identical to setting the default value for
> text fields and list boxes to true, and the others to false.

Sure, that could work, as long as the default was indeed set that way.
(Defaults are just as important for developers as for users. Notice for
example how often labels in new GTK applications are incorrectly
centered, merely because centering is incorrectly the default alignment
for text labels in Glade.)

>...
>> (b) when they did set it they'd often set it inconsistently
>> between windows and apps,
> 
> That sounds like trying to enforce the Gnome HIG on toolkit basis,
> which is in my oppinion a very bad idea. gtk+ is used by lots of
> non-Gnome applications, and I consider this to be a good thing.

I don't understand what you mean. The Gnome HIGs currently do not cover
which controls should be in the Tab cycle (they don't mention that
toolbar buttons shouldn't be included, for example), precisely because
that's the sort of thing that should be handled by the toolkit instead
of by individual applications.

Naturally, the default behavior would vary depending on which platform a
GTK application was running on. (Gecko does this with its
accessibility.tabfocus option.)

> Also, this can never be 100% consistent, because for different apps,
> different widgets are important. Even an entry widget may only be used
> in very rare cases, and thus wouldn't belong in this chain.

I'm prepared to accept this might be necessary, but I doubt it. Can you
give a real-life example of a text field in a window where Tab works for
cycling focus at all (i.e. there's no document or spreadsheet area where
Tab means something else), but where it shouldn't include that text
field?

>> and (c) users would not be able to tell by looking at a window
>> whether Tab was going to do what they wanted.
> 
> This is true, but just as well for your suggestion. How would the user
> know beforehand if custom widgets will be included in the tab cycle?
>...

By whether they look like lists or text fields.

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