Re: WM enhancements to support accessible screen lock



On Wednesday 08 of October 2003 14:25, Bill Haneman wrote:
> On Wed, 2003-10-08 at 13:12, Lubos Lunak wrote:
[snip]
> > > 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.

 Mouse button grabs. That's how other applications can get mouse events, 
unless the pointer is grabbed. And it's not really the same like those other 
ways to circumvent the lock, I'm talking about normal applications that the 
user could normally run, not some sniffing tool.

 To be specific, I'm talking about gestures (also known as strokes or 
whatever). E.g. FVWM has support for them AFAIK, and since FVWM is 
extensively configurable, I'd guess that they can perform a lot of things in 
FVWM. Also with KDE3.2 there will be a utility that will be able to do 
basically anything after performing a gesture as well.

 And I don't really consider pointer grabbing that problematic. The locking 
app can simply detect which window is at the event coordinates, and forward 
the event to the appropriate window if it's necessary. Is this really more 
complicated that trying to check and adjust all apps that have global input 
triggers?

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

 See above. Some applications check user input even if they're not shown at 
all.

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




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