Hello Anselm R. Garbe on Tue, Jan 16, 2007 at 12:13:46PM CET, you wrote:
> This depends on how you define idleness.
Idleness in the sense of no user input: no mouse movement or clicks and
no keyboard activity either.
> I assume writing data to the lbar or rbar should be ignored?
Yes, status script within the bar like a clock or system load, etc.
should still update their data.
> If so, it should be safe,
> because the bar drawing should not produce any X events if no
> client covers the bar.
As far as I know the current wmii does not allow clients to overlay the
bar, neither in floating nor in managed mode.
But it is a very interesting issue to keep in mind when wmii behavior
changes is regard to the overlaying of the bar.
Since I am not too familiar with X11 / Xlib programming, what events
would be generated if a client was to overlay 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.
That sounds like a good first approach to get acquainted with the task.
The callback solution you proposed is definitely the right direction to
head to. Thank you for your valuable input.
> 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.
I agree on that, even though it has a certain appeal for idle detection
would be handled independently from wmii.
Greetz Alexis
-- Tip 51: Don't Gather Requirements - Dig for Them -- The Pragmatic ProgrammerReceived on Tue Jan 16 2007 - 17:21:43 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:18:39 UTC