Re: [wmii] Idle Detection Feature Proposal

From: Anselm R. Garbe <>
Date: Tue, 16 Jan 2007 12:13:46 +0100

On Tue, Jan 16, 2007 at 11:57:38AM +0100, Alexis Hildebrandt wrote:
> Denis has been kind enough to add a couple events, which enhance the
> scriptability of wmii. Thanks a lot for that =)
> Two events that could be very useful in combination with slock (or other
> screen locking mechanism for that matter) are:
> Idle & Active
> What do you think?
> Is that a feature you could be interested in?
> Is there another feasible solution already available, that runs slock
> after a configurable time of user idleness?
> I have no idea whether the event loops used in wmii or libixp support
> idle detection or not. I'll have a look if someone that knows the wmii
> and libixp code by heart points me to a location where I could start
> digging.

This depends on how you define idleness. I assume writing data
to the lbar or rbar should be ignored? If so, it should be safe,
because the bar drawing should not produce any X events if no
client covers the bar.

Hence, I propose determining idleness with checking the
timestamp of last X event (ev.time). You should have a look to
event.c:check_x_event() - you have to remember the ev.time after
the XNextEvent(blz.dpy, &ev); call. You wether might want to
patch libixp to add a hook to the select loop
(libixp/server.c:ixp_server_loop()) - maybe a timeout for
extending libixp with a timer implementation (just add some
callbacks which can be registered being invoked on select
timeouts) - if such timeouts happen, you check within the
registered timeout handler from within wmii if current time -
ev.time > EPSILON, and if so you write_event('IdleTimer'); or
something like that...

A more ugly solution would be to hook into the rbar/lbar
processing and check for the idle timeout there (but this
requires status writers at least) - might be simplier, but as I
told, much more ugly.


 Anselm R. Garbe >< >< GPG key: 0D73F361
Received on Tue Jan 16 2007 - 12:13:46 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:18:37 UTC