Re: WM enhancements to support accessible screen lock

[David Bolter <david bolter utoronto ca>]

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 
http://www.freedesktop.org/standards/wm-spec/1.3-onehtml/#id2963955

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.


cheers,

David
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
> http://mail.gnome.org/mailman/listinfo/wm-spec-list