Re: WM enhancements to support accessible screen lock

[Lubos Lunak <l lunak suse cz>]

On Thursday 25 of September 2003 12:21, 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.

 You misunderstood. I don't mind supporting accessibility windows _also_ in 
the WM, if that proves to be necessary or essential. What I don't like is 
using WM for keeping the stack order while the screen is locked, and leaving 
the input ungrabbed. Normal desktop status (i.e. when not locked) and locked 
screen are two different things, and I consider them so different that I find 
it better not to handle locked screen by WM but rather by the locking app.

 Actually, kdesktop_lock already does some basic stacking order management (as 
you have the locking window, the password dialog, and more dialog that can be 
shown above the password dialog - the "do you really want to start new 
session?" dialog, IIRC). Adding support for keeping accessibility windows 
above the lock screen in kdesktop_lock should be fairly simple, in fact 
probably simpler than adding it to KWin.

>
> 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).

 I don't mind doing that in WM, under normal conditions. (This would of course 
mean that while the screen would be locked, WM would temporarily cease to 
manage stacking order for these windows - even then, I still consider it 
simpler).

>
> 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.

 KWin currently doesn't any functionality related to screen locking.

>  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.

 Forwarding mouse events from the lock program to the accessibility windows 
should ba fairly simple, as I already said. Keyboard would be more difficult, 
if that would be really necessary.

>
> 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 ;-)

 Are you sure they are worse than the third one?

(3) make screen lock useless

 Since I think that a screen lock that doesn't grab the input is useless.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/