On Mon, Apr 10, 2006 at 03:11:49PM +0200, Julien Claassen wrote: Hello Julien, This is a tricky subject, and most toolkits have their own peculiar methods of solving the problem. In general terms this needs callback functions - a function supplied as a creation parameter to the widget, and which it will call when it has something to report. In C this is quite easy to arrange. The widget is given a function pointer, and usually also a void* which becomes the first argument of the callback fucntion and points to any context the receiver wants to be available when called back. Other arguments depend on what the callback needs to report. In C++ you will want class function members to act as callbacks, and here things get complicated. Since callback functions are strongly typed and this type depends on the class they are in, there is no single variable type you can put into the widget to hold the function pointer. Three solutions: 1. All callbacks first go to a static class function which in most compilers have "C" semantics. So this requires two functions for each callback, the first static one which is seen by the widget as a plain C function, and which then calls the second one. In that case the void* mentioned above would point to the C++ object that receives the call, and the static callback casts it to the right class pointer type and then calls the class member function via that pointer. 2. Use templates. This is nicely encapsulated in GLib, part of GTK, which you can probably re-use (it doesn't depend on the graphical stuff AFAIK). 3. Define on or more callback classes, containing on or more virtual functions. All receiver classes inherit from this or these classses, and a pointer to this type is passed at creation time to each widget. This is what I use in libclxclient. Unless you want to do a lot of things yourself, I guess the GLib way will be the easiest, or else stick to plain C (complicating matters for C++ users, by forcing them to use the indirect callback method explained above). -- FA Follie! Follie! Delirio vano e' questo!

Julien Claassen wrote: Most GUIs are "Event" driven by means of message passing. The GUI would just listen to the messages from the "Engine" and send messages to the engine. The listening thread would register it's interest in a particular message queue. This is done by the listening thread informing the "Engine" of it's callback function via a function pointer. The "Engine" would simply build up a linked list of all the listeners for a particular queue, and then call each callback function for each and every message it received. So, if the user "push a button", that causes a message to be added to the message queue. The "Engine" would then call all the callback functions saying "push a button", so all the listeners now know that a button was pressed. James