• Create the socket with G_SOCKET_TYPE_SEQPACKET and G_SOCKET_PROTOCOL_SCTP instead of G_SOCKET_TYPE_DATAGRAM and G_SOCKET_PROTOCOL_UDP, respectively.
• Use g_socket_listen() to start receiving messages.

The relevant code parts now look like this:

GSocket *sock;
GError *err = NULL;
sock = g_socket_new(G_SOCKET_FAMILY_IPV6,
                    G_SOCKET_TYPE_SEQPACKET,
                    G_SOCKET_PROTOCOL_SCTP,
                    &err);
g_assert(err == NULL);

g_socket_bind(sock,
              G_SOCKET_ADDRESS(addr),
              TRUE,
              &err);
g_assert(err == NULL);

int fd = g_socket_get_fd(sock);
GIOChannel* channel = g_io_channel_unix_new(fd);
guint source = g_io_add_watch(channel, G_IO_IN,
                              (GIOFunc) callback_function, data);
g_io_channel_unref(channel);

g_socket_listen(sock, &err);
g_assert(err == NULL);

Sadly, it seems like there are no functions for GSocket to use lower level SCTP features, like getting the list of peer and local IP addresses in the association. I suppose this is possible by using the normal low level functions (e.g. sctp_getpaddrs()) on the file descriptor returned by g_socket_get_fd(), but I haven’t tried yet.

1. Incoming data on the UDP socket creates an event in the GLib main loop.
2. The event callback function starts a handler thread from a GThreadPool.
3. The thread locks a mutex for the socket, reads from the socket, maybe sends a reply (depends on the received message), unlocks the mutex and returns.

Looks harmless? It isn’t. The program used a signal callback to stop the main loop on SIGTERM. This would allow any remaining threads to finish their work before the program terminates. When I tested that, I was surprised that the server would not stop. I had to add a lot of debug output until I found the reason.

The problem was that the messages were read from the socket in the threads. The event callback returned after starting the thread, and the main loop continued to run. In the short time between thread start and socket read, the event would fire again and again, because the data was still available on the socket. This was enough to launch all handler threads in my 4 member thread pool.

The result: The first thread gets the mutex, reads the message, does its work, unlocks the mutex and returns. While the first thread reads, there are 3 more threads waiting for the mutex. When the first thread is done, one of the others grabs the mutex and tries to read. I used blocking functions, so it waits until a new message arrives. A new message fires an event, which starts another thread. I suppose you get the idea. All handler threads were trying to process incoming messages simultaneously! By the way, the SIGTERM callback actually worked. After SIGTERM, no new events and therefore no handler threads were created, and after receiving enough messages the server did indeed terminate, because each thread returned after processing its message.

This is why I wrote that a mutex is not enough. Yes, the mutex prevented the threads reading from the socket at the same time, but it did not stop the event. The solution was, of course, to read the message in the event callback and point the handler thread at the data. Lesson learned: Don’t just think about “Could these threads try to access something at the same time?” and throw in a mutex if the answer is yes. Threaded operation can create a lot of unintended connections, and it’s easy to overlook one of them. Take care, and you can avoid a long debugging session like the one I had today.

Obviously, a GSocket is necessary. I want my socket to listen on IPv6 UDP. I know that assertions are not the best error handling, but they are good enough for an example.

GSocket *sock;
GError *err = NULL;
sock = g_socket_new(G_SOCKET_FAMILY_IPV6,
                    G_SOCKET_TYPE_DATAGRAM,
                    G_SOCKET_PROTOCOL_UDP,
                    &err);
g_assert(err == NULL);

Bind the socket (addr is the GInetSocketAddress* to listen on):

g_socket_bind(sock,
              G_SOCKET_ADDRESS(addr),
              TRUE,
              &err);
g_assert(err == NULL);

Hint: if you want to listen on all interfaces, use g_inet_address_new_any() to create the GInetAddress part of the socket’s address. Under Linux “any IPv6 address” includes IPv4, I don’t know if this applies on other platforms as well.

To get an event when the socket receives data, the following steps are necessary:

1. Get a file descriptor for the socket.
2. Use the file descriptor to create a GIOChannel for the socket.
3. Add a watch for the G_IO_IN condition on the channel.

int fd = g_socket_get_fd(sock);
GIOChannel* channel = g_io_channel_unix_new(fd);
guint source = g_io_add_watch(channel, G_IO_IN,
                              (GIOFunc) callback_function, data);
g_io_channel_unref(channel);

The callback_function has to match the GIOFunc pattern. It must not block, so I use it to start a thread which will do the real work. The main loop needs to be initialized before attaching the event. After the event is attached, just run the main loop (if you need more info about that, look here). Cleaning up is pretty simple: Use g_source_remove(source) to disconnect the event source and g_object_unref() the objects.

• Which functions do I have to implement?
• Where should I define what struct?
• Do I need to allocate the private memory?
• Should the object struct contain a pointer to the private memory?

Here are the answers that I found:

Necessary functions

Four functions are the absolute minimum: init, class_init, dispose and finalize. For a class named example, you would need the following declarations in the header:

static void example_init(Example *self);
static void example_class_init(ExampleClass *klass);
static void example_dispose(GObject *gobject);
static void example_finalize(GObject *gobject);

The argument to class_init should be called klass to avoid confusion with the C++ class keyword.

Structs

The object und class structs have to be declared and defined in the header (example). You can put the private data struct declaration into the header or source, the definition should definitely be in the source file. I would recommend putting the typedef into the header, because it will allow you to add a pointer to the private memory into the object struct. Put something like this into the header:

typedef struct _Example Example;
typedef struct _ExampleClass ExampleClass;
typedef struct _ExamplePrivate ExamplePrivate;

struct _Example {
	GObject parent_instance;
	/* instance members */
	ExamplePrivate *priv;
};

struct _ExampleClass {
	GObjectClass parent_class;
	/* class members */
};

The definition of struct _ExamplePrivate goes into the source file. The contents of the private structure is entirely your decision.

Allocating and accessing private memory

Register the private memory with the object system using g_type_class_add_private() in your class’ class_init() function. It will be allocated automatically when you use G_TYPE_INSTANCE_GET_PRIVATE for the first time, and freed automatically as well. However, you have to take care of any dynamically allocated memory in the private data. To quote the manual:

“You don’t need to free or allocate the private structure, only the objects or pointers that it may contain.”

If you use the source layout recommended in the manual, you will get a useful macro called something like EXAMPLE_GET_PRIVATE which returns a pointer to the private memory. Using a *priv pointer is not necessary (you could use GET_PRIVATE each time you need it), but it is a good idea to improve performance (the macro does a few function calls).

You can see how to register and get private memory in the example source file, look at the maman_bar_class_init() and maman_bar_init() functions and the MAMAN_BAR_GET_PRIVATE macro.

GTK+ already supports multiple mouse pointers, but only in it’s git version. The GTK+ page for MPX is available here. In this post, I will discuss how to compile and run GTK+ with MPX support. The following has been tested on Archlinux, but should work for any other Linux distribution.

Before we start, we need to make sure, our system meets the necessary dependencies (see here for a list). When we are sure the dependencies are met, we need to install GLib from source since GTK+ depends on it. This is how we install GLib and update pkg-config:

$ git clone git://git.gnome.org/glib
$ cd glib
$ ./autogen.sh --prefix=<your path to glib>
$ make
$ make install
$ sudo cp <your path to glib>/pkgconfig/* /usr/lib/pkgconfig/

Now we are ready to get the sources of GTK+:

$ git clone git://git.gnome.org/gtk+/

You can now switch to the 2.90.2 tag if you want:

$ git checkout 2.90.2

Next, we can configure and compile the xi2 branch and update pkgconfig:

$ ./autogen.sh --prefix=<path to gtk>
$ make
$ make install
$ sudo cp <path to gtk>/lib/pkgconfig/* /usr/lib/pkgconfig/

GTK+ should now be working with MPX support. To compile files with gtk+-3.0, you can use:

gcc <file> -o <name> `pkg-config --cflags --libs gtk+-3.0`

To test the installed GTK+, we need to create a new master in xinput and add a new pointer device:

xinput create-master <name>
xinput list
xinput reattach <device id> <new master pointer id>

You can now run the tests in the GTK+ sources  (Update: the test has been removed since the branch was merged, but you can find an example of how to use multipointer input in GTK here):

cd <path to gtk+ sources>/tests/multidevice
make
./testcoordinates

Mask#9 is one of a series based on a single photo.  This print tries to convey the smooth superficiality of today’s public faces. Who or what are they? I can’t quite make out, they might be…then again…. look away, look back. Everything changes.

See more prints and drawings by  Dennis and Susan at our Etsy store  Galerie Yggdrasil

But they will not allow you to enjoy your freedom indefinitely. Mother needs an assistant when she gets old. A number of fathers will try to get you entangled for their daughters. In India, an unmarried girl is a curse on her parents. If nothing else, your friends come forward to help you. I think such things are unknown in the West.

Once married, there is no going back. You are tied for seven lives, one after another.

Every day you have to bring vegetables, milk and such things in addition to taking her for shopping, cinema and visiting friends. As soon as you come back from your work place, tired and angry, on account of the bickerings and fights with your colleagues and the irrational Boss, she will be waiting, fully dressed, to go out. Not her fault, as she is kept inside the house, bored to death. Well get fresh, change your dress and go out.

When children are born, at least two, there is no end to your worries. Worries are multiplied, with the children fighting each other, then school, tuition, home work and all that.

Wife falling ill, in-laws coming and all sorts of complications.

If she is beautiful (who will marry an ugly girl?), you are suspicious of that idle fellow, who is always so sweet and glib tongued.

And, when you want to do it, she is not in the mood.

Before you realised it, your daughter has grown too big. Now it is your turn, to hunt for a husband for her.

W-I-F-E means, Worry Invited For Ever !.

Should I create a new library (named libbyteunits or similar) or add a bunch of new functions to glib (as replacement for g_format_size_for_display)? Is glib the right place for ten or more functions handling units?

Pros for a separate library:

• the library can be used by non-glib application without depending on glib
• it can be made user configurable (for example by an text file), because some user prefer base-10, others base-2.

Cons:

• one more dependency for glib applications

I like to hear as many opinions as possible. Please let me also know, if you are glib developer, a g_format_size_for_display() using developer, a developer, or a user.

DESCRIPTION:

Design, implement, and support high quality, high performance consumer-facing software applications for web-connected devices. This role involves hands-on development and oversight of core components of the product, in collaboration with a software team that spans internal and external distributed development teams. Ideal candidates will have prior experience with both designing and leveraging communication (e.g., IM, e-mail, VOIP) frameworks and rich media user interface development.

• Analyze product definition and define software requirements within your domain. Consult with product management and architects to create an optimal design and plan for user interface and/or service components to meet an aggressive product schedule
• Evaluate, integrate, and enhance 3^rd party APIs and technologies, tailoring the provided functionality to meet the needs
• Identify possible pitfalls and provide practical alternatives/solutions.

QUALIFICATIONS

REQUIRED SKILLS AND EXPERIENCES

• 5+ years of experience developing complex Internet-connected communication applications in C/C++.
• Deep hands-on development experience with email and messaging technologies (IMAP, POP3, MAPI)
• Deep knowledge of Network technologies – proxy server, load balancers, TCP/IP, UDP
• Experience with TCP/IP socket level communication development
• Development experience with scripting languages (e.g., Python, Lua, JavaScript, ActionScript)
• Hands on development with software libraries and object systems (e.g., GLib, GObject, LibXML, libjpeg)
• Experience designing and implementing complex data-driven systems, including optimizations.
• Experience with development on Linux platforms and tool chains.
• Must be able to work with project stakeholders to analyze, understand and implement user requirements.
• Strong desire to work in a dynamic team environment, including oversight of remote development.
• Strong desire to get “outside of the box” and explore solutions from a variety of perspectives and make appropriate technical tradeoffs.
• Must work quickly, creatively & decisively, delivering designs to suit product / project requirements

DESIRED SKILLS AND EXPERIENCES

• Experience with skinning applications on media frameworks and UI toolkits (e.g., XBMC)
• Experience with social networking API’s (e.g., Facebook Connect)
• Experience with SOAP/REST style web services
• User centric design, user experience design
• Excellent communication & presentation skills.

If this position interests you, please send your resume, your hourly rate, and your interview availability to raj@mindsource.com.

DESCRIPTION:

Design, implement, and support high quality, high performance consumer-facing software applications for web-connected devices. This role involves hands-on development and oversight of core components of the product, in collaboration with a software team that spans internal and external distributed development teams. Ideal candidates will have prior experience with both designing and implementing media frameworks and rich media user interface development.

• Analyze product definition and define software requirements within your domain. Consult with product management and architects to create an optimal design and plan for user interface and/or service components to meet an aggressive product schedule
• Evaluate, integrate, and enhance 3^rd party APIs and technologies, tailoring the provided functionality to meet the needs
• Identify possible pitfalls and provide practical alternatives/solutions.

QUALIFICATIONS:

REQUIRED SKILLS AND EXPERIENCES

• 5+ years of experience developing complex Internet-connected entertainment applications in C/C++.
• Significant, current experience developing consumer-facing UIs and designing and implementing underlying media APIs and frameworks
• Development experience with scripting languages (e.g., Python, Lua, JavaScript, ActionScript)
• Hands on development with software libraries and object systems (e.g., GLib, GObject, LibXML, libjpeg)
• Experience designing and implementing complex data-driven systems, including optimizations.
• Experience with development on Linux platforms, tool chains, and associated libraries
• Must be able to work with project stakeholders to analyze, understand and implement user requirements.
• Strong desire to work in a dynamic team environment, including oversight of remote development.
• Strong desire to get “outside of the box” and explore solutions from a variety of perspectives and make appropriate technical tradeoffs.
• Must work quickly, creatively & decisively, delivering designs to suit product / project requirements

DESIRED SKILLS AND EXPERIENCES:

• Experience with skinning applications on media frameworks and UI toolkits (e.g., XBMC)
• Knowledge of email and messaging technologies (IMAP, POP3, MAPI)
• Hands-on development experience with social networking APIs
• Experience with SOAP/REST style web services
• User centric design, user experience design
• Excellent communication & presentation skills.

If this position interests you, please send your resume, your hourly rate, and your interview availability to kathy@mindsource.com.

(From Wikipedia) The Knight’s Tour is a mathematical problem involving a knight on a chessboard. The knight is placed on the empty board and, moving according to the rules of chess, must visit each square exactly once. A knight’s tour is called a closed tour if the knight ends on a square attacking the square from which it began (so that it may tour the board again immediately with the same path). Otherwise the tour is open.

Just developed my brute-force algorithm implementation, using GLib and based on a simple recursive function.

Download and try it here!

As an example of result, this is the open Knight’s Tour found by the algorithm in a 5×5 board, starting from position [0,0]:
[0,0][1,2][2,4][4,3][3,1][1,0][2,2][0,3][1,1][3,0][4,2][3,4][1,3][0,1][2,0][4,1][3,3][1,4][0,2][2,1][4,0][3,2][4,4][2,3][0,4]

And this one, the first Knight’s Tour found by the algorithm in a 8×8 board, starting from position [0,0]:
[0,0][1,2][2,4][3,6][5,7][7,6][6,4][7,2][6,0][4,1][5,3][6,5][7,7][5,6][7,5][6,3][7,1][5,0][6,2][7,4][5,5][6,7][4,6][5,4][6,6][4,5][3,3][5,2][7,3][6,1][4,0][2,1][4,2][3,0][1,1][0,3][2,2][0,1][2,0][3,2][4,4][2,3][0,4][1,6][3,7][2,5][1,7][0,5][1,3][3,4][1,5][0,7][2,6][4,7][3,5][2,7][0,6][1,4][0,2][1,0][3,1][4,3][5,1][7,0]

Both examples above show open Knight’s Tours.

D-Bus is a message passing system (IPC) that is light, fast and is now rapidly replacing its predecessors like DCOP. Messages between different processes travel in buses, the D-Bus daemon routes them. You can think of the system as a wheel with spokes attached; the daemon forms the crux/hub and the each spoke is a bus thru’ which process’ talk. D-Bus, now, is a part of all the Linux distributions I know. Reason is, many primary desktop applications/utilities of desktop environments like Gnome, KDE, Xfce, etc. use it under the hood. Enough theory, let’s get down to business

Two parts of the problem are:

1. Detecting if it’s the primary instance
2. Passing a message to the primary instance, if duplicate

Deducing the instance

Each process requests a bus to the D-Bus daemon thru’ which it can pass its messages. This bus can be assigned a unique name. Once a unqiue name is granted, other requests, by different buses, to have the same name fails or is put in queue until the owner bus relinquishes / quits. Using this we can solve part one of the problem.

// this header is a part of the dbus dev. headers
#include <dbus/dbus.h>

#define STR_UNIQUE_BUS_NAME		"some.bus_name.unique"

DBusConnection *bus = NULL;
DBusError err = {0};

bool is_primary_instance()
{
	int ret_code = 0;

	bus = dbus_bus_get(DBUS_BUS_SESSION, &err);

	if(dbus_error_is_set(&err))
		goto deal_with_error;

	printf("Bus obtained!\n");

	ret_code = dbus_bus_request_name(bus,
					STR_UNIQUE_BUS_NAME,
					DBUS_NAME_FLAG_DO_NOT_QUEUE,
					&err);
	if(dbus_error_is_set(&err))
		goto deal_with_error;

	if(DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER == ret_code)
		return true;

deal_with_error:
	if(dbus_error_is_set(&err))
	{
		fprint(stderr, "D-Bus Error: %s\n", err.message);
		dbus_error_free(&err);
	}

	return false;
}

Registering for signals

Now for part two of the solution: in case of a primary instance, we should register for a possible signal from our potential duplicates, with a set of rules; in case of a duplicate instance, it should send a signal to the D-Bus daemon, abiding by the rules set by the primary, so that the primary instance gets intimated of the signal, by the daemon.

#define STR_DUPLICATE_OBJECT_PATH	"/some/object/path"
#define STR_INTERFACE_DUPLICATE		"some.interfacename.duplicate"
#define STR_SIGNAL_NAME			"duplicate_instance_invoked"
#define STR_SIGNAL_MATCH_RULE		"type='signal',interface='some.interfacename.duplicate',path='/some/object/path'"

// function that registers with D-Bus for a message of type = signal
// and from interface named some.interfacename.duplicate
bool register_signal()
{
	dbus_bus_add_match(bus, STR_SIGNAL_MATCH_RULE, &err);
	if(dbus_error_is_set(&err))
	{
		fprint(stderr, "Error registering rule: %s\n", err.message);
		dbus_error_free(&err);

		return false;
	}

	printf("Signal match rule added!!\n");

	//signal_sighter is our callback function which is called when a
	// signal comes from our duplicates

	return dbus_connection_add_filter(bus, signal_sighter, NULL, NULL);

}

// actual function that handles the signals from duplicates
DBusHandlerResult signal_sighter(DBusConnection *connection, DBusMessage *message, void *user_data)
{
	if(dbus_message_is_signal(message, STR_INTERFACE_DUPLICATE, STR_SIGNAL_NAME))
	{
		printf("Signal received!\n");
		return DBUS_HANDLER_RESULT_HANDLED;
	}

	return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}

Sending the signal

In case of a duplicate instance, it should signal the primary instance that a duplicate was invoked.

void signal_primary()
{
	DBusMessage *mesg = NULL;

	mesg = dbus_message_new_signal(STR_DUPLICATE_OBJECT_PATH, STR_INTERFACE_DUPLICATE, STR_SIGNAL_NAME);
	dbus_connection_send(bus, mesg, NULL);

	dbus_message_unref(mesg);
	mesg = NULL;
}

Note: If you’re trying this out using Glib/GTK, that has a main loop like g_main_run() or gtk_main(), you need to add the following too:

// this header will be part of the dbus-glib dev. headers
#include <dbus/dbus-glib-lowlevel.h>

// add this line after the dbus_bus_get()
dbus_connection_setup_with_g_main(bus, NULL);

Hope this helps! Do bug me for your queries.

P.S.: One can argue that libunique is a better choice for creating single instance apps., but the problem is libunique works only with GUI programs, while this method works for both CLI and GUI programs. Also, libunique uses D-Bus under the hood

Now, after re-reading carefully the GLib Reference Manual, I see that it is quite clearly explained the difference between g_source_destroy() and g_source_unref(). So the typical suggestion is still the best one: RTFM!!

In our applications, we usually need to attach timeout operations to the context of an specific thread, not to the main thread context. Thus, we cannot use g_timeout_add() or the pretty new g_timeout_add_seconds().

For example, you could create a GThreadPool, and in the function to be executed in each thread, you could create a specific context for the thread, plus a main loop in the context:

    /* Create a GLib Main Context */
    context = g_main_context_new();

    /* Create a Main Loop in the context*/
    main_loop = g_main_loop_new(context,
                                FALSE);

Once you have a new context and main loop, you can just create a new GSource, and attach it to the main loop. As soon as you create the GSource, its reference count is 1, and as soon as you attach it to the main loop, its reference count will be 2.

    /* Create new timeout source to be called
     * every 5 seconds.
     * Reference count of source is 1 once created */
    source = g_timeout_source_new(TIMEOUT_MSECS);

    /* Set callback to be called in each timeout */
    g_source_set_callback(source,
                          (GSourceFunc)__timeout_func,
                          main_loop,
                          NULL);

    /* Attach the GSource in the GMainContext.
     * Reference count of source is 2 after this call */
    g_source_attach(source,
                    context);

Of, course, you will be now running the main loop:

    /* Run the main loop, until it is stopped */
    g_main_loop_run(main_loop);

The key now is how to destroy the GSource properly. When calling g_source_destroy(), you are doing 2 things: first, telling the main loop to forget about the GSource; and second, decrementing the reference count of the GSource. Then, you still need to call g_source_unref() to fully decrement the reference counter so that the GSource is disposed.

    /* We did an attach() with the GSource, so we need to
     * destroy() it */
    g_source_destroy(source);

    /* We need to unref() the GSource to end the last reference
     * we got */
    g_source_unref(source);

To end the example, once the main loop is stopped, you will also need to properly dispose the GMainContext and GMainLoop objects:

    /* The main loop should be destroyed before the context */
    g_main_loop_unref(main_loop);

    /* Finally, destroy the context */
    g_main_context_unref(context);

This is just one way of keeping the GSource references properly managed:

1. You get one reference when you create the GSource
2. You get a new reference when you attach it in the context
3. You release one reference when you destroy it from the context
4. You release last reference when you unref the final one

Of course, you could also choose to avoid storing the “extra” reference, and leave alive only the one inside the main context:

1. You get one reference when you create the GSource
2. You get a new reference when you attach it in the context
3. You release one reference when you unref the the GSource —> Now, the only reference is inside the GMainContext
4. You release last reference when you destroy it from the context

You can check this simple example in the following program I prepared, released into public domain:
http://es.gnu.org/~aleksander/glib/test-gsource.c

Hope it helps someone out there to fully understand the difference between g_source_destroy() and g_source_unref().

As last comment… I would really rename the following functions in the library, so that no one else is confused with the “unref” and “destroy” terms:

• Rename g_source_attach() to g_source_attach_to_context()
• Rename g_source_destroy() to g_source_destroy_from_context()

The main reason is that these two operations actually act on the GMainContext, while the name of the functions do not suggest that fact.

Then, when I finish shaking my head, I suppose I am not the only person who has thoughts like this. And I wonder how it came to pass that God, who didn’t stop this or that genocide, that God, who didn’t stop Lenin on his way to the Finland Station, decided to perform such and such miracle for me that night in Montana in July of 2000.

Caveat lector: I am, at least to a modest degree, inclined to be philosophical, but I am not inclined to read or study philosophy. And thus I do not have any idea how this question has played out in great minds through the ages. I can only give the conclusions I inevitably come to when my mind wanders this way. On the question of God, I conceive the following possibilities:

1. There is no God.
2. God is not good.
3. God is not competent.
4. God’s principles are similar to those of the Chicago economists.

And that thing that happened in Montana? Was it just good luck?

Bom, foi feito um exemplo e aqui está:

Primeiro criei uma classe GlibYield. Ela simplesmente pega um iterável e agenda seu próximo passo usando glib.idle_add(). Criei três funções que servem de ganchos para subclasses desta classe.

A idéia aqui é que a função que está sendo monitorada será escrita com uma série de yields que a tornarão um gerador. Este gerador então será consumido a cada passo, e pode-se fazer qualquer coisa entre estes passos.

Na listagem abaixo, eu usei glib.timeout_add(1000, …) ao invés de glib.idle_add(…), para que demore mesmo um tempo entre cada passo. Ao usar em um caso real, troque pela linha glib.idle_add() comentada.

import pygtk
pygtk.require('2.0')
import gtk
import glib

class GlibYield(object):
    def __call__(self, iterable, *args, **kwds):
        obj = self.before_start(*args, **kwds)
        glib.timeout_add(1000, self.step, iter(iterable), obj)
#        glib.idle_add(self.step, iter(iterator), obj)

    def step(self, iterator, obj):
        try:
            data = next(iterator)
        except StopIteration:
            self.on_end(obj)
        else:
            obj = self.on_step(data, obj)
            glib.timeout_add(1000, self.step, iterator, obj)
#            glib.idle_add(self.step, iterator, obj)
        return False

    def before_start(self, *args, **kwds): pass
    def on_step(self, data, monitor_obj): pass
    def on_end(self, monitor_obj):  pass

Criei então uma subclasse de GlibYield que cria uma barra de progresso em um certo container (que você passa como parâmetro) e a atualiza com os valores que vem da função sendo executada:

class GtkProgressCreator(GlibYield):
    def __init__(self, container):
        self._container = container

    def before_start(self, title='Aguarde...'):
        pb = gtk.ProgressBar()
        if title:
            pb.set_text(title)
        self._container.pack_start(pb, True, True, 0) # TODO: incluir formas de customizar isso
        pb.show()
        return pb

    def on_step(self, data, pb):
        pb.set_fraction(data)
        return pb

    def on_end(self, pb):
        pb.destroy()

Aqui temos um exemplo da utilização da classe. O método calcula() é uma função geradora. Ao clicar no botão, ele é executado, criando um objeto gerador, que é passado para o GtkProgressCreator. Este então cria uma barra de progresso, e a atualiza toda vez que o gerador dá um yield, reagendando o próximo passo pela glib.

class TestStep(object):
    def clicou(self, widget, data):
        print "Calculando..."
        # Executa a funcao no GtkProgressCreator
        self.pc(self.calcula(15, 14, 5))

    def calcula(self, n1, n2, n3):
        r = n1 + n2
        yield 0.25 #cada yield atualiza a barra de progresso e libera a GUI

        r = r * n3
        print 'Estamos na metade...'
        yield 0.5

        r = r / n1
        yield 0.75

        r = r ^ n2
        yield 1

        print 'RESULTADO ENCONTRADO: ', r

    def delete_event(self, widget, event, data=None):
        gtk.main_quit()
        return False

    def __init__(self):
        self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
        self.window.set_title("Teste de Step!")
        self.window.connect("delete_event", self.delete_event)
        self.window.set_border_width(10)
        self.box1 = gtk.VBox(False, 0)
        self.window.add(self.box1)
        self.button1 = gtk.Button("Calcular")
        self.button1.connect("clicked", self.clicou, 1)
        self.box1.pack_start(self.button1, True, True, 0)
        self.button1.show()
        self.box1.show()
        self.window.show()

        # Cria um progresscreator que criara barras de progresso em box1
        self.pc = GtkProgressCreator(self.box1)

def main():
    gtk.main()

if __name__ == "__main__":
    s = TestStep()
    main()

Existem alguns problemas com esta implementação – A principal é que ela não é boa com operações que duram muito tempo entre os yields, pois a GUI ficará travada nestes pontos. Nestes casos demorados, a operação geralmente depende de fatores externos – leitura de arquivos, acesso de rede – e aí o melhor seria utilizar as funções corretas da glib para eses casos (glib.io_add_watch). O gerador então poderia até injetar os resultados de cada chamada destas de volta na função através do http://docs.python.org/reference/expressions.html#generator.send ; Até pensei em escrever algo assim e atualizar depois o post.

Porém eu desisti. Porque melhor que tudo isso é usar twisted com um reactor GTK. Twisted possui deferreds – na verdade este código acima foi inspirado no http://twistedmatrix.com/documents/current/api/twisted.internet.defer.html#inlineCallbacks e é uma “versão pobre” deste esquema.

Mesmo assim foi divertido escrevê-la, e funciona! Veja como ficou ao clicar 4 vezes no botão rapidamente:

4 barras de progresso atualizadas independentemente

From the article:

He loved museums, architecture, reading, first edition books, the theater, seeing four movies in one day with his friend Annette Williams; the clothes at Barneys, Bergdorf and Armani; cosmetics counters, face creams, spas, manicures and pedicures; travel; five-star hotels; Swiss Style design; Helvetica typeface; the simple beauty of a straight, clean line…

As his first lover and lifelong best friend, Wesley Mancini, a fabric designer, said, “His 40s were definitely the best decade of his life.” He was making a (low) six-figure salary at Lauder, and in 2001, moved from an Upper East Side studio to a one-bedroom in the heart of Chelsea’s gay community. He supported the Gay Men’s Health Crisis, marched yearly in the AIDS walks and volunteered to deliver food to a senior center in the West Village.

People lose jobs all the time and don’t kill themselves. Why Steven Schnipper? Scott [his brother], who’s now 51 and an editor at Bloomberg News, said he knew that Steven was depressed and was seeing a therapist, but didn’t understand he suffered major depression. “I think it was masked by his work and income and the prestige of the jobs at the cosmetics companies. This stripped away his protective layer. Steven couldn’t think straight.”

And then, at the end of the article:

For a while they worried how to explain the suicide to Adam [the nephew of the deceased], but then they decided the easiest way was to tell him the truth: Uncle Steven died of a disease called depression.

Is this true? Did he die of depression? He certainly had a lot to be depressed about! I can imagine Samuel Johnson declaring that he died from vanity and love of luxury, and even if I’m not inclined to make such a harsh judgment myself, still I think it’s strange to say he died from depression.

Would depression have killed him if he hadn’t gotten laid off? If not, then wouldn’t it be better to say that he died because he lost his job? The article says, “people lose jobs all the time and don’t kill themselves,” and of course that’s true, but it’s also true that while most people who are struck by lightning—or bitten by a black widow spider—live, we still say that those who die, die from lightning strike or spider bite.

Layoffs, lightning strikes, spider bites—all of these things can be fatal, if the circumstances are right. As every twelve-year-old boy obsessed with venomous creatures knows, black widow venom can kill children and the elderly, but not healthy adults.

With layoffs the situation is reversed: it’s healthy adults who are most vulnerable, especially those with no dependents, those whose sense of worth is connected to professional achievments, those for whom luxury has become necessity, and those who are, to put it bluntly, post-Christian.

It is very possible that, far from being unable to “think straight,” Uncle Steven knew just what he was doing.

An agenda of no-agenda is singularly easy for a president to enact. Any other kind of agenda is going to be much more difficult. Bush was set for four, or possibly even eight, comfortable years of steady hand on the tiller.

But then the world turned upside down, and Bush discovered his real vocation. And however one may view the agenda he subsequently developed, it so happened that he was able to accomplish a good deal of it.

How did he do it? How can a president do anything?

The answer to that is: for the last fifty years or so the  president hasn’t been able to do much at all, at least not at home.  He is like Gulliver in Lilliput (and Lilliput, of course, is Congress).

What presidents accomplish, what presidents are remembered for, is what they do abroad. A president tries to enact a domestic agenda at his own peril. The USA belongs to the Senators and Representatives. Basically, it belongs to the lobbies.

I’m not trying to make a conspiracy theory. A lot of lobbies work against one another, and a lot of them represent not the interests of a few but the interests of many (for example, the largest lobby of all, which is not the AARP or the NRA or even the AFL-CIA — that’s a joke; see Whit Stillman’s Barcelona  — is the lobby of drivers, so strong it needn’t even be organized).

Compared to what he’s up against at home, abroad the president practically has a free hand, and how much more true is this in a time of crisis. Congress still has to approve the budget, but when the Gulliver in the White House has a flag wrapped around him, toga-like, all of the Lilliputians scurry off to look for their own little togas.

The lesson for Obama? You shouldn’t have bothered. One way or another we seem to be coming out of our recession. Whether or not you are responsible for this, your reward will be no reward at all.

Abroad, you’re doing your best to fulfill Bush’s goals in Iraq and Afghanistan. (Of course this is the right thing to do!) And since his goals require the full capacity of our armed forces, you’re not exactly in a position to develop any geopolitical goals of your own.

At home, well, you’ll always have Ms. Sotomayor.