Re: WM enhancements to support accessible screen lock

I completely agree. I think what we proceed in figuring out whether we should add a new WM_TYPE or a stacking order rule.

Looking at

I wonder if we should add a WM_STATE "_NET_WM_STATE_ABOVEALL indicates that the window should be on top of all windows, to be used when there would be disastrous results if the window were occluded"

And the stacking order text might read:

"Stacking order

To obtain good interoperability between different Desktop Environments, the following layered stacking order is recommended, from the bottom:

    * windows of type _NET_WM_TYPE_DESKTOP
    * windows having state _NET_WM_STATE_BELOW
    * windows not belonging in any other layer
* windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE
    * focused windows having state _NET_WM_STATE_FULLSCREEN
    * focused windows having state _NET_WM_STATE_ABOVEALL

Windows that are transient for another window should be kept above this window.

The window manager may choose* to put some windows in different stacking positions, for example to allow the user to bring currently a active window to the top and return it back when the window looses focus.

*Except in the case of _NET_WM_STATE_ABOVEALL which must never be occluded

In the case of multiple windows with _NET_WM_STATE_ABOVEALL, the most recently active window wins. This state should be used sparingly for such things as on-screen input software and screen magnifiers."

It appears there is some overlap b/w TYPE and STATE so I am not sure where this belongs. My experience with X is miniscule.


Bill Haneman wrote:
Since the WM is the agent which enforces stacking order now, I think the
WM is where the special stacking requirements of assistive technologies
should be provided for/respected.  I don't see this as a particular
additional complication, it's just a matter of adding a new WM_TYPE or
stacking order rule.

Doing this in the lock dialog fails to address a number of problems;
lock dialogs are not the only applications out there that break
assistive technologies by posting obscuring windows on top.  IMO the
only way to deal with override-redirect issues in general is to modify
the stacking order rules for WMs, in particular with regard to
override-redirects (at the moment managed windows are never supposed to
be raised by the WM above override-redirects; windows like the GOK main
window would need to be exceptions to this rule).

Note that keyboard and mouse locking isn't particularly secure anyhow,
there are lots of exploits that can be used by clients who can connect
to the X server.  The best you can do is prevent windows other than the
'lock' window from grabbing keyboard focus, and here again this is
really the WM's responsibility.  If one doesn't allow GOK to receive
mouse events, then you are effectively disabling GOK which defeats its
purpose and locks the user out of the desktop.

The alternatives to providing these capabilities are:

(1) don't allow disabled users to use your desktop;
(2) don't allow GOK users to run a screenlock program.

Clearly these are not acceptable alternatives ;-)

best regards,

- Bill

wm-spec-list mailing list
wm-spec-list gnome org

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