Re: keyboard/focus annoyance after sorting in list view
- From: Rui Tiago Cação Matos <tiagomatos gmail com>
- To: Holger Berndt <berndth gmx de>
- Cc: Usability Mailing List <usability gnome org>, nautilus-list gnome org, Alexander Larsson <alexl redhat com>
- Subject: Re: keyboard/focus annoyance after sorting in list view
- Date: Fri, 6 Mar 2009 11:03:16 +0000
[ added usability gnome org to cc ]
2009/3/6 Holger Berndt <berndth gmx de>:
> 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.
>
> 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.
>
> Closing the loop to the other thread, Ctrl-Tab would then be an alias
> to Tab if the global switch is set to true.
>
> Alternatively, the global switch could be left out completely, and
> Ctrl-Tab be made an iterator that only considers these "important"
> widgets.
Agree. Teaching gtk+ about such a property would be very useful and
Alt+Tab could indeed be overloaded with what the HIG currently assigns
it to:
"Ctrl+Tab, Shift+Ctrl+Tab Moves keyboard focus out of enclosing widget
to next/previous control, in those situations where Tab alone has
another function (e.g. GtkTextView)"
This paragraph is, I think, completely compatible with "Moves keyboard
focus among important user input widgets" since the widgets where Tab
alone would behave differently from the "Move to next widget" seem to
be among the ones which would be marked as "important".
Rui
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]