WM enhancements to support accessible screen lock

[Brian Cameron <Brian Cameron Sun COM>]

Perhaps the largest remaining accessibility hole on the GNOME desktop today
is the lack of an accessible screen lock mechanism.  In order for the lock
screen to be properly accessible, the relationship between the screensaver
and the window manager will likely need to become more intimate.

This is because some AT programs (such as GOK - the GNOME On-Screen Keyboard)
have graphical user interfaces which, in order to function properly, must
remain visible and interactive even on top of a running screen lock program.

Currently the only two AT programs that have GUI's are GOK and Gnopernicus.
Of these, GOK is the only program that requires that its GUI is always
available.  GOK displays a keyboard on the screen, and the user can hover
the mouse or alternative XInput pointer over particular "keys" in order
to send that character to the window that has focus.  Note that the GOK
window itself never accepts focus.  Since the GUI in Gnopernicus is only
used for setting preferences, it is probably acceptable that it would
not be available during screen lock.

That said, the mechanism that we implement for supporting AT programs when
the screen is locked should be general.  It is likely that in the future
additional AT programs will be developed that may also require that their
GUI's be constantly available, even when the screen is locked.  Therefore,
it would be ideal if such future programs would just work.

Most current lock screen programs run as "override redirect" windows, to
ensure that they get placed on top of all windows, and use GrabKey and
GrabPointer in order to ensure that the screen lock program is appropriately
secure.  However, I believe these mechanisms are simply too crude to
support an AT program such as GOK.

To support accessibility, the job of controlling window stacking order
should perhaps instead be controlled by the window manager.  In other
words, the screen saver would no longer run as "override redirect" and
instead the screen manager would ensure that the screen lock program would
be at the appropriate stacking order.

The "appropriate stacking order" would mean that various AT programs
that have GUI interfaces could mark themselves with a new window manager
type, perhaps WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED.  Such programs would
be displayed in front of the screen lock program, and all programs
without this type would be hidden behind the screen lock program.

In addition, the window manager would need to provide the following
services:

+  To ensure that all key/mouse events are not allowed to propegate
   to any program that is hidden behind the screen lock program.

+  When the screen lock program is running, mechanisms like Alt-Ctrl-Tab
   would allow the user to cycle *only* between programs that are
   marked with WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED and the screen lock
   program itself.

+  To display the screen lock program without window decoration so that
   it is more clear that the window cannot be resized/moved/minimized/
   shaded/killed/etc.

It might be necessary for the window manager to somehow mark programs
that are of type WM_TYPE_VISIBLE_WHEN_SCREEN_LOCKED so that such windows
are more visibly different than normal windows.

It would also be useful to have a new root window message, perhaps
SCREEN_LOCKED, so that various AT programs can respond appropriately
when the screen becomes locked.  There might be certain features (such as
user-preferences) which should be disabled when the screen is locked.
This way someone couldn't maliciously change the user's GOK preferences
while the screen is locked.

Obviously in order for the screen lock program to be accessible, it
will also be necessary for the lock screen dialogs to use a widget
set that supports ATK, the most likely candidate being GTK+.

--

Brian