Re: Panel Accessibility - Key Nav

[Bill Haneman <bill haneman sun com>]

Havoc Pennington wrote:
...

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

This would be bad for the virtual keyboard unless we could distinguish
docks that wanted keyboard focus from those that should always reject
keyboard focus.  GOK has to reject focus otherwise it can't effectively
inject key events into other windows.  So if DOCK means 'stay on top
near edges' that's ideal, and useful for lots of things.  But we'd need
a way to maintain input->false and non-WM_TAKE_FOCUS protocol
capability.
 
> 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

right, glad this is not the case with sawfish.

> 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 not a big fan of triple-key combos, especially for
accessibility-related things.  

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

Maybe, if that would not require the WM to have too much knowledge of
the panel.

-Bill

> Havoc