Re: keyboard/focus annoyance after sorting in list view

[Alexander Larsson <alexl redhat com>]

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.

> Also what struck me when checking the above was that in all cases, 
> there's an easy way to jump OUT of the main pane, but no easy way to 
> jump back IN ("jump" as in a single key/key combo consistently gets you 
> to a certain control). But you agree with me there, and that's been 
> taken up in another sub-thread. :-)

There is not particular key that gets you directly to *any* widget. Tab
affects the focus-chain, not particular widgets. This is something
completely different. However, its quite useful to have. And I think its
something many apps may want. I.E. a "focus the document widget"
keybinding.