Re: keyboard/focus annoyance after sorting in list view

[John Keller <gnome johnkeller com>]

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.

I don't know, seems like a usability factors ("what do we need to have") 
plus accessibility ("what can we do without") question.

> > 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.

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. :-)

> > Not sure, is all that related to GTK or expected behavior? If not, maybe 
> > Ctrl-Tab could always jump to/switch between the main file list and the 
> > sidebar. I know that I've often seen that used in similar situations in 
> > GNOME (Ctrl+Tab or Ctrl+PgUp/PgDown to switch between tabs in a dialog 
> > box) or in Windows (often used to switch between tabs in an MDI, whereas 
> > GNOME usually Ctrl+PgUp/PgDown, e.g. Nautilus itself).
>
> In another thread I proposed using a function key, lets keep the
> discussion there.

Sure, sorry - just was thinking of context of my reply.

- John