I want the keboard for navigation too, but I never really liked the
"move cyclicly between application, or move cyclicly between panes of an
application window" scheme of navigation.

How about this - move the focus using the menus.
We could have menus look like this -
   Go to -> (application defined sub menu that lists related menus. For
the world, all the immidiate submorphs. For a category list, just the
class list, and so on.)
   Focus here (put the keyboard focus on the morph owning this menu)
   Go up (Application defined "next up". By default, the World menu,
from a browser code pane the method pane, from a method pane the class
pane, and so forth...)
   <Here go all the regular menu options, with the first initially
selected, for easy access>

Doug Way <dway at riskmetrics.com> wrote:
> Cool stuff!
> 
> We're almost all the way to supporting keyboard-only operation of the UI. (at least the traditional SystemWindow/menu portion of the UI)
> 
> Not that I'd willingly give up using the mouse, but it'd be nice to be able to support mouseless operation.
> 
> About the only other things we'd need would be to be able to bring different windows to the fore with the keyboard (someone wrote a goodie to do this long ago), and to be able to switch keyboard focus between different panes within a SystemWindow.  Perhaps ctrl-tab or ctrl-arrow or similar could do this pane switching.
> 
> (Although I guess we'd also need a stronger form of sticky keyboard focus to support this, similar to what Steve Swerling submitted.)
> 
> Also, I tend to agree with Daniel Vainsencher that it would be more useful for the ESC key to bring up the local list/editor pop-up menu inside a list/text morph, rather than the World menu.  Maybe Shift-ESC or something else could bring up a World menu everywhere.
> 
> - Doug Way
>   dway at riskmetrics.com