On Fri, 2009-03-06 at 12:13 +0100, John Keller wrote:
Alexander Larsson wrote:
On Fri, 2009-03-06 at 11:23 +0100, John Keller wrote:
Alexander Larsson wrote:
Really? Is this a global switch? How is it decided which elements are
allowed to be focused?
Yes, it's global. Not sure how long it exists (OS X only? And since
which version), but I ran into it recently.
It basically turns off keyboard nav (tab/arrow keys) between
non-modifiable fields. So e.g. buttons in dialog boxes (Enter and Escape
still confirm and cancel, and there are mneumonic-but-not-displayed
shortcuts like Command-D for "Don't save changes" in a confirmation
dialog or Command-D for "Desktop" in save dialog boxes). I'd have to
check, but I believe it's still possible to to toggle with the keyboard
between the file list and the spotlight search field on each Finder window.
Interesting. Something like this in gtk+ would perhaps be a better match
for what you want?
Sure, though I don't know how I'd define that. "Text fields and
treeviews only"? But then, outside of Nautilus maybe a treeview would be
less important for key nav than some other control. Which would bring it
back to the app to define, even if there's a global switch.
All editable widgets would probably be a pretty good start. Then add
perhaps the default focused widget in the window.,
I don't know, seems like a usability factors ("what do we need to have")
plus accessibility ("what can we do without") question.
Clearly this option is totally non-accessible, its rather to avoid some
of the issues created by a11y. So I'm not sure why you bring it up.
Currently, Ctrl-Tab seems to be used to jump to/navigate between the
toolbar buttons in browser view (in list or icon view); and to/between
the sort fields and the little path button in the corner of the folder
view (in list view), or to/between the little path button and the main
pane's contents (in icon view).
Hmm, internal consistency, anyone? ;-)
The hig says:
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)
According to the Gtk+ source it moves by default as if Ctrl is not set,
but various widgets override this (like the toolbar).
I meant more the internal consistency of Nautilus. Depending on the
combination of browse/folder view and list/icon view, we see three
different behaviors. I hadn't noticed these ever before, but thought it
was worth mentioning since it seemed germane.
Tab switches between widgets in the tab chain, and we have different tab
chains in list view and icon view. I don't see how that is
"inconsistent":
In list view the only difference between tab and ctrl tab is that if the
tree view is focused ctrl-tab will focus the next non-treeview widget,
while tab will first focus other following (before or after depending on
shift status) internal widgets.
In icon view there are no widgets that special handle "ctrl-tab", so
there is no differences.
In browser view the same behaviour as above affects the views.
Furthermore, ctrl-tab is handled by the toolbar meanin "toggle focus
between the items in the currently focused toolbar".
This is the same behaviour as in any other Gtk+ app with toolbars or
treeviews.