Re: Panel Accessibility - Key Nav

[Havoc Pennington <hp redhat com>]

Bill Haneman <bill haneman sun com> writes: 
> OK, this is just by limited understanding, so I could be way wrong here
> ;-)
> but I think sawfish doesn't understand 'panel' as anykind of special
> entity, except that maybe it's override-redirect or something.  In other
> words I don't know if it's currently possible for the WM to know that
> something is a panel and thus should be omitted from the usual WM focus
> sequence, or to know that it should be included in a special 'panel
> focus' chain.
> 
> Given that these smell like sawfish changes to me, I would vote for the
> temporary expedient of including Panel in the focus sequence - this
> could be a user-configurable thing to keep from having consistency
> problems with the default setup later on.

The new WM spec (which Sawfish supports) does distinguish type DOCK
from other kinds of window. We need to keep in mind however that
Sawfish won't be able to distinguish the GNOME panel from other sorts
of "stay on top around the edges of the desktop" sort of apps - so
e.g. the virtual keyboard or magnifier might be treated the same way
as the panel.

If the panel were override redirect (as it is for non-spec-compliant
WMs), the window manager wouldn't see it _at all_ - so it would be
impossible for any WM keybinding to affect it in any way. Override
redirect means "invisible to window managers" basically; window
managers work by "redirecting" map and configure requests from apps,
override redirect windows override that redirection.

My thought was that it might make sense to have a second tab order for
the panel, e.g. Alt+Tab does normal windows, Ctrl+Alt+Tab goes through
dock windows, and adding Shift to either reverses the order of tab
motion.

I'm also wondering if we shouldn't move the global key shortcuts in
the panel into the window manager - there are some edge cases we could
handle then, such as conflicts between those shortcuts and the WM
shortcuts.

Havoc