Re: WM enhancements to support accessible screen lock

[Bill Haneman <Bill Haneman Sun COM>]

On Wed, 2003-10-08 at 13:12, Lubos Lunak wrote:
...
> > 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
> 
>  I think this except clause is not really useful, as you should never say 
> never :).

Well, the 'never' part is key to the meaning/utility of ABOVEALL as it
was stated.  So omitting it makes the concept less useful.
...
>  Maybe this state should be rather a window type?

That was my original thought; that we needed a new window type rather
than a new window state.  I think this would be compatible with the
current use cases.
> >
> > There was still debate regarding whether the GrabKeyboard was necessary
> > at lock screen time.  Generally people agreed that the GrabPointer could
> > safely be removed.
> 
>  I can do a lot of things with just the mouse in KDE3.2 as long as it's not 
> grabbed, regardless of what's visible on the screen. 

Can you provide some examples?  I don't know of any situations where you
can meaningfully accomplish anything if the WM is preventing
applications other than the screensaver/lock programs from taking focus
and being in the foreground.  Applications don't normally receive mouse
events unless their XWindows are visible, and as we've already
discussed, other ways of getting mouse info (besides normal X pointer
event delivery) can circumvent the lock anyhow.

> Moreover, the reasoning 
> that grabs are actually useless was based on claiming that one can run apps 
> that will get some information about the input even if the pointer is locked. 
> However, I fail to see how such apps could be run with input grabbed (and if 
> somebody lets somebody else to run it while the screen is not locked, it's 
> not really the lock's problem). 

The same could be said for applications that subvert the WM's efforts to
manage X focus, or otherwise 'allow the user to do things' when their
application X windows are obscured by the lock and/or screensaver
windows.
 
- Bill