Re: [Usability] keyboard/focus annoyance after sorting in list view
- From: Holger Berndt <berndth gmx de>
- To: nautilus-list gnome org
- Cc: Usability <usability gnome org>
- Subject: Re: [Usability] keyboard/focus annoyance after sorting in list view
- Date: Mon, 9 Mar 2009 10:23:19 +0100
On So, 08.03.2009 21:47, Matthew Paul Thomas wrote:
>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.
What you are proposing is in fact an (in my oppinion unnecessarily)
restricted version of the same thing.
>> 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.
Only that it's more restrictive (on toolkit level!).
>(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.
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.
> 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?
Holger
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]