Re: WM enhancements to support accessible screen lock

[Bill Haneman <Bill Haneman Sun COM>]

I concur with Brian's summary, except for one matter:

I do not think that ABOVEALL should always be posted above FULLSCREEN,
but rather that the window manager should allow ABOVEALL windows to
raise themselves above FULLSCREEN.  This would allow onscreen keyboards
to be viewed above fullscreen windows such as video presentations
on-demand, while retaining the onscreen keyboard user's ability to view
actual-fullscreen content.  

I would also add the behavioral change that ABOVEALL windows be allowed
to raise themselves above all windows including override-redirect
windows.  So in summary I would suggest stacking order:

>      * 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_ABOVEALL
>      * focused windows having state _NET_WM_STATE_FULLSCREEN

and add that 'raise' requests from windows having state
_NET_WM_STATE_ABOVEALL should always be honored and result in their
being raised to the top of the stacking order, including
override-redirect windows.  Note that the ABOVEALL property should not
depend on focus since onscreen keyboard windows should not as a rule
take keyboard focus.

- Bill

On Tue, 2003-10-07 at 00:03, Brian Cameron wrote:
> 
> Last month, there was some discussion regarding how accessible screen locking
> can be supported.  Although there was some debate regarding whether it is
> best for the locking to be managed by the window manager or a separate screen
> locking program.
> 
> Either way, however, I think it was pretty much agreed upon that new window
> manager extensions would be needed in order to make clear which programs need
> to be visible on top of the screen lock program.  There were basically two
> 
> David Bolter, the GOK maintainer had the following suggestion of adding
> 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 was also recommended that the _NET_WM_STATE_ABOVEALL would only be honored
> if this message were set before the screen is actually locked.  In other words,
> if the state is changed to _NET_WM_STATE_ABOVEALL after the screen is locked,
> that window would not be visible.  This would prevent a hacker from changing
> the state of a particular window and getting it to appear above the lock
> screen.
> 
> It was also suggested that there should be a window manager message to
> indicate that the screen is currently in a locked state.  This message could
> be WM_SCREEN_LOCKED.  Other programs could listen for this message, and turn
> off certain features when the screen is locked.  For example, a program like
> GOK or Gnopernicus could turn off the ability to change preference settings
> in order to prevent a malicious user from changing the preferences to an
> unusable state for the person who locked the screen.
> 
> Lastly, it was suggested that somehow windows that are of type
> _NET_WM_STATE_ABOVEALL should be visibly distinct from other windows.
> This way the user is always clear about which windows will be visible
> even when the screen is locked.  Perhaps there could be an additional
> icon in the menubar that indicates this state.  I would be open to
> suggestions here.
> 
> There was still debate regarding whether the GrabKeyboard was necessary
> at lock screen time.  Generally people agreed that the GrabPointer could
> safely be removed.  Since GOK is currently the main program that requires
> lock screen support, and since GOK only requires pointer input, then it
> seems like we might be approaching a solution that allows on-screen
> keyboards to be used at login time, which would be a big step in the
> right direction.
> 
> There was debate regarding whether or not it would be more appropriate
> to have the screen lock handled by the window manager, or by a standalone
> lock program that honored this proposed protocol.  I think this is an
> implementation detail and can be ignored at this time.
> 
> At any rate, this topic seemed to end a few weeks ago.  I wanted to
> summarize the current state of the proposal, and to hopefully get
> further feedback.
> 
> Thanks!
> 
> -- 
> 
> Brian
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list