Re: keyboard/focus annoyance after sorting in list view

[John Keller <gnome johnkeller com>]

Alexander Larsson wrote:
> 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.

I only brought it up because I didn't know whether suggesting to exactly 
duplicate Mac behavior was the best. (E.g. maybe there would be concerns 
that too much was taken out, like perhaps OK/Cancel/etc. buttons should 
remain in the chain.)

But yes, I realize that it's clearly non-accessible since it pretty much 
takes everything out of the focus chain that wouldn't otherwise accept 
text input. ;-)

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

OK. As I said in the other sub-thread, thanks for taking the time to 
explain. It's understandable when you explain it like that. The docs 
that I'd looked at (HIG, as referred to here) don't do such a hot job 
("x behaves the same as y except for cases where it's different", in 
essence). It could be that I've overlooked sources, but I don't think 
I'm the only one in that case and certainly not the only one who wasn't 
clear on this. Not your fault, which is why I appreciate your taking the 
time to educate on it.

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

Exactly, and as I mentioned I'm happy that you like the idea of adding 
this kind of idea (whether it's at GTK level or app level).

- John