Re: Panel Accessibility - Key Nav

Glynn Foster wrote:
> Okay, I might as well post some of the writeups that Calum did for
> keyboard navigation [hope this is okay Calum ;)]...

> The panel needs to be able to gain focus somehow.  From the user's point
> of view, there would probably need to be a window manager shortcut to do
> this 
> Additionally or alternatively, there
> should probably be a way of specifying you want some/all of your panels
> to appear in the Tasklist applet, and also in the sequence as you cycle
> your way with Alt+Tab through the available windows.

and later, jumping ahead...

> Once a panel has focus, probably want to be able to cycle focus between
> other panels on the desktop-- so we could have just one desktop-wide
> shortcut for "give focus to panels", 

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.

Personally I don't see including Panel in the regular focus chain as a
problem anyhow, but I'm not an HCI guy per se...

> How to show a panel has focus-- is giving the first
> menu/drawer/launcher/applet focus enough?  Doing so would be in keeping
> with the way we show that a toolbar has focus, so maybe yes.

I think that just indicating focus to the panel without pre-selecting a
panel item is nicer.  I think either arrow keys or tabs would be fine
for focus keynav.  I don't see using Tab as a problem, most setups
require Alt-Tab for window-to-window nav anyhow, so keeping Tab inside a
panel seems OK and avoids the problems with arrow keys Calum mentions. 
Focus indication could be a focus line drawn around the whole panel, or
some other visual indication (maybe the background changes from NORMAL
to ACTIVE).  We do want the panel to use themes don't we?  I think that
even bitmap backgrounds for Panel should come from the theme.

> Problem: that would mean using arrow keys to move focus between objects
> on a panel, which could be a problem with various applets that need

If we treat the Panel as "just another window" with some specialized
widgets, then it all becomes both consistent and limits key clashes to
those we already have to deal with.  I'm all for this, including keeping
the Panel (optionally) in the WM focus chain.  Most of these "howto"
questions are then already answered for us :-)

> You can currently copy or move a panel object from one panel to another
> with [Ctrl+]drag and drop.  If we wanted to provide keyboard equivalents
> for this, we'd probably either need to look at doing it with
> Cut/Copy/Paste-type shortcuts, or build new functionality into the panel
> menus explicitly for this purpose.  Possibly not an issue for a first
> cut, though.

Another possibility is to create "drag" and "drop" AtkActions, so you
can do this via assistive technology instead.  Not perhaps the most
general solution for users who just don't use a mouse, but something
anyway.  MouseKeys (part of AccessX) might make this possible for
sighted keyboard-only users.


> _______________________________________________
> gnome-2-0-list mailing list
> gnome-2-0-list gnome org
gnome-hackers mailing list
gnome-hackers gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]