Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Sun, 22 Jan 2012 18:06:06 +0100

On 21 January 2012 01:13, Bjartur Thorlacius <svartman95_AT_gmail.com> wrote:
> Þann fös 20.jan 2012 23:42, skrifaði Rob:
>>
>> On Fri, Jan 20, 2012 at 07:01:22PM +0000, Bjartur Thorlacius wrote:
>>   Surely it just destroys the window, you can't get a PID for any X
>> window,
>> since it could be a networked one
>>
>
> As I expected. The PID is usually stored in a window property, as is the
> hostname, of every or most windows. But this is a flat out bug in slock.
> Slock should survive window destruction, right?

Did anyone reproduce this issue with slock? I'm not totally convinced
that slock is really affected by this bug, as slock does not perform a
grab on the window it creates, but on the root window instead. However
there are the possibility that when the slock window is destroyed an
uncaught XError call will exit forcefully (due to the default error
handler).

I pushed a change that adds a dummy error handler instead. Please
could anyone test hg tip if it is still affected?
(Though the correct handling will be recreating the particular slock
window as well).

Having said all this, there is still another problem in slock. If you
launch a client *after* slock has taken over (like over a SSH
connection), the window will be managed and most likely appear on top
of slock (the window won't receive any input though). This problem is
actually to make slock play more nicely (instead of grabbing the
server).

The easiest solution to this problem would be to handle exposure
events and to re-raise in that case (still we need some tweaks to
cover the window lifecycle)...

This will make slock's architecture a bit more complex, however please
see the above solution for a short term fix.

Cheers,
Anselm
Received on Sun Jan 22 2012 - 18:06:06 CET