Re: How to identify the idle state of the GTK+ application?

[Gus Koppel <gtk spamkiller bytechase cx>]

sadhees kumar wrote:

>        In my GTK application, If  no action(event) is taken place in
> the screen, I need to turn OFF the backlight of an TFT monitor. If any
> key pressed, or mouse movement occured, I need to turn ON the
> backlight.
>
> I have the API for toggling the backlight. My problem is , how to
> identify the idle state of the screen?

First, I hope you know that your GTK+ application usually doesn't
represent (or own) the screen. It's just one application of possibly
many, which have windows opened and wait for any user actions or system
events to take place in order to process them. Via GTK+ you can control
and monitor only your own application, not other ones. While your
application could think it's idleing, other applications (or applets)
could feel quite busy at the same time. So intending to turn on / off
the screen based on whether your application feels idle or not sounds
inherently unsuitable, if not dangerous.

However, there are two exceptions when you can assume that your
application has full control over the entire screen. I don't suppose any
of them apply to you. They are
1. GTK+ on framebuffer and
2. GTK+ Cursed.
Apparently both of them are not well (or not at all) maintained lately.

Back to your actual question: what you want are two things:
1. determine whenever the main loop executes an iteration
2. get informed when there are no main loop iterations for some time.

I have no detailed solution for your question at this time, but I can
point you at some areas which you should examine. I think you should use
g_main_context_set_poll_func() for your program to be informed about
every main loop iteration that takes place. Your own function should do
three things:
1. determine whether the iteration was caused by a timeout event
2. set a global timestamp flag if not caused by timeout
3. call original poll() function to maintain operational reliability

Use g_timeout_add() to install a function to be called periodically to
check how old the last main loop iteration timestamp is. If now() -
timestamp > backlight_turn_off_wait_time then you turn off the backlight
using your own API.

The main problem of this strategy is to determine within your own
GPollFunc whether the main loop iteration was triggered by the timeout
function or by anything else. The timestamp must be updated only if not
your timeout function was triggering the iteration. There's no easy way
to determine the sort of event that triggered the main loop iteration
within your GPollFunc. You will have to study GLib sources to check
whether there's a somewhat clean way to determine the type of event from
within it. It's not going to be easy stuff. Creating an ordinary
screensaver-like process would be easier, indeed.

See:
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-main-context-default
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-main-context-set-poll-func
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-timeout-add