Timeouts, I/O and Idle Functions

Timeouts
You may be wondering how to make gtkmm do useful work while it's idling along. Happily, you have several options. Using the following methods you can create a timeout method that will be called every few milliseconds.

sigc::connection Glib::SignalTimeout::connect(const sigc::slot<bool>& slot,
                                      unsigned int interval, int priority = Glib::PRIORITY_DEFAULT);

The first argument is a slot you wish to have called when the timeout occurs. The second argument is the number of milliseconds between calls to that method. You receive a sigc::connection object that can be used to deactivate the connection using its disconnect() method:

my_connection.disconnect();

Another way of destroying the connection is your signal handler. It has to be of the type sigc::slot<bool>. As you see from the definition your signal handler has to return a value of the type bool. A definition of a sample method might look like this:

bool MyCallback() { std::cout << "Hello World!\n" << std::endl; return true; }

You can stop the timeout method by returning false from your signal handler. Therefore, if you want your method to be called repeatedly, it should return true.
Here's an example of this technique:
Source Code

Monitoring I/O
A nifty feature of Glib (one of the libraries underlying gtkmm) is the ability to have it check for data on a file descriptor for you. This is especially useful for networking applications. The following method is used to do this:

sigc::connection Glib::SignalIO::connect(const sigc::slot<bool,Glib::IOCondition>& slot,
                                 int fd, Glib::IOCondition condition,
                                 int priority = Glib::PRIORITY_DEFAULT);

The first argument is a slot you wish to have called when the specified event (see argument 3) occurs on the file descriptor you specify using argument two. Argument three may be one or more (using |) of:
Glib::IO_IN - Call your method when there is data ready for reading on your file descriptor.
Glib::IO_OUT - Call your method when the file descriptor is ready for writing.
Glib::IO_PRI - Call your method when the file descriptor has urgent data to be read.
Glib::IO_ERR - Call your method when an error has occurred on the file descriptor.
Glib::IO_HUP - Call your method when hung up (the connection has been broken usually for pipes and sockets).
The return value is a sigc::connection that may be used to stop monitoring this file descriptor using its disconnect() method. The slot signal handler should be declared as follows:

bool input_callback(Glib::IOCondition condition);

where condition is as specified above. As usual the slot is created with sigc::mem_fun() (for a member method of an object), or sigc::ptr_fun() (for a function).
A little example follows. To use the example just execute it from a terminal; it doesn't create a window. It will create a pipe named testfifo in the current directory. Then start another shell and execute echo "Hello" > testfifo. The example will print each line you enter until you execute echo "Q" > testfifo.
Source Code

Idle Functions
If you want to specify a method that gets called when nothing else is happening, use the following:

sigc::connection  Glib::SignalIdle::connect(const sigc::slot<bool>& slot,
                                    int priority = Glib::PRIORITY_DEFAULT_IDLE);

This causes gtkmm to call the specified method whenever nothing else is happening. You can add a priority (lower numbers are higher priorities). There are two ways to remove the signal handler: calling disconnect() on the sigc::connection object, or returning false in the signal handler, which should be declared as follows:

bool idleFunc();

Since this is very similar to the methods above this explanation should be sufficient to understand what's going on. However, here's a little example:
Source Code
This example points out the difference of idle and timeout methods a little. If you need methods that are called periodically, and speed is not very important, then you want timeout methods. If you want methods that are called as often as possible (like calculating a fractal in background), then use idle methods.
Try executing the example and increasing the system load. The upper progress bar will increase steadily; the lower one will slow down.