nautilus-list@gnome.org
[Top] [All Lists]

Re: keyboard/focus annoyance after sorting in list view

Subject: Re: keyboard/focus annoyance after sorting in list view
From: John Keller
Date: Fri, 06 Mar 2009 12:13:15 +0100
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
--
nautilus-list mailing list
nautilus-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/nautilus-list

<Prev in Thread] Current Thread [Next in Thread>