Re: keyboard/focus annoyance after sorting in list view

[John Keller <gnome johnkeller com>]

Alexander Larsson wrote:
> On Fri, 2009-03-06 at 08:43 +0100, John Keller wrote:
> > Alexander Larsson wrote:
> > > On Sun, 2009-02-22 at 21:35 +0100, florian wrote:
> > >
> > > > imo the up/down key binding should be changed so that pressing up moves 
> > > > the selection in the file list up... and not the selection of a 
> > > > different widget in the gui.
> > > This is the general behaviour of the Gtk+ tree widget (and Gtk+ in
> > > general). When you click on the list view header you change focus to the
> > > header "widget". This means further key events go to that widget and not
> > > the list itself. For these widgets the arrow keys control changing the
> > > focus widget, so you can change focus to another widget.
> > >
> > > Changing this is imho a bad idea, as it breaks keyboard navigation of
> > > the GUI, so that you can't e.g. use it without a mouse. It also causes
> > > problems for accessibility.
> > I often get annoyed at the behavior caused by the keyboard navigation 
> > guidelines, even though I understand very well why it's there. (Also 
> > being told that it's the way I "expect" [as in "people expect", in 
> > another thread recently here] things to be is a bit annoying, but that's 
> > a different subject ;-) ).
>
> It certainly may not be the way everyone expects a computer to behave,
> but its the way other gtk+ apps does. And as these other apps look the
> same people generally expect them to act the same too. Even if they
> consider it wrong. :)

Yeah, I know. And believe me, I'm for consistency. Just feel that 
sometimes people get so hung up on defending keyboard 
navigation/accessibility that they don't take into consideration the 
other cases. E.g. the opposite of ignoring accessibility or consistency 
to make some app "ultra efficient" to use.

> So, consider my comment being about changing the nautilus behavior to be
> other than other apps. I don't have anything per-se against changing
> details of gtk+ behaviour that will affect all apps.

Sure, understood. Nothing personal, I just often see that kind of 
comment in GNOME world used as an closing argument instead of a starting 
point.

> > The way it's implemented makes it difficult for people who *don't* want 
> > to use the keyboard to navigate everything. Why is it that it's all or 
> > nothing? Even Apple provides a switch for this (basically, on/off - with 
> > "off" allowing only certain elements to be focused by keyboard).
>
> 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.

On the other hand, the Mac never had the same "must have keyboard nav" 
ethic. That was IBM with CUI standards, made popular with Windows 3.x 
and even more with Windows 95, to my memory. The original Mac didn't 
have cursor keys (to "encourage" use of mouse), and I don't remember 
when Home/End PgUp/PgDown keys were added (to this day, they mean 
something different than for other platforms, and the arrow keys + 
sometimes modifier do their Windows/Linux function).

> > But maybe that's the GTK stack. There's also the application level. 
> > Forgive my ignorance if this already exists, but I think that at the 
> > very least Nautilus could give a keyboard shortcut that gives focus to 
> > the file list frame, no matter where the focus is elsewhere in the 
> > window. The way things are, it requires juggling the mouse and the 
> > keyboard (or counting keystrokes/monitoring the screen closely when 
> > using keyboard only).
>
> This isn't a bad idea. Does any other app have this, and if so what
> shortcut are they using?

I honestly don't know, it was just an idea off the top of my head. Of 
course, it'd be hard to replace the simplicity of Tab or an arrow key 
alone (since really the only other single-key options are Fx keys and 
those are frowned upon).

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? ;-)

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

> It sort of goes with the split view too, where that key could be used to
> switch between views.

Yeah, that makes sense now that you mention it. If Ctrl-Tab were used 
per above, then it might make sense to have its navigation chain be the 
two panes in the split view plus the sidebar.

- John