Qt->glib main event loop patch (common main loop)

Matthias Ettrich ettrich at trolltech.com
Sun Nov 13 18:48:18 GMT 2005


On Saturday 12 November 2005 20:36, Gary Greene wrote:
[...]
> B) GParts
> Another interesting project which would benefit from a common main loop,
> is GParts (http://gparts.blogspot.com/).
> Dmitry M. Shatrov gave me some demo-code which worked well with the
> patched Qt. One example embeds KTHML into a Gtk+ window. I put a
> screenshot here: http://www.scheinwelt.at/~norbertf/common_main_loop/

You can do that without patching Qt, and definitely without having all of KDE 
depend on Glib, even in Qt 3.

Qt's event loop is flexible enough (even in Qt 3) to hook a Glib event loop 
into it. One of the issues I had last time I did this was that Glib didn't 
give me the information when the next Glib timer was supposed to fire. You 
need that to set the proper timeout for the select statement. I remember 
having patched Glib to provide that. My patch didn't get in, but I do 
remember that Havoc told me in newer versions everything I needed should be 
available.

I also suggested at one point to develop a common event loop abstraction for 
Unix C/C++ toolkits. A small, self-contained library that every toolkit can 
use. Basically a glorified select() abstraction.This wasn't met with much 
enthusiasm, more with "glib is exactly that". And so is QtCore, and Xt :-)

What we then did in Qt 4 is making out abstraction even more open and simpler 
to enhance. We use this ourselves when integrating with e.g. Eclipse (which 
on Unix is SWT/Gtk+, in other words Glib), or Motif (which is the Xt event 
looop).  Instead of making Qt work with Glib, why not patch Gtk to use Xt, 
then both Qt and Gtk can use the standard Xt loop? Qt supports this with it's 
Motif extension.

The Unix desktop is a mess.

 Matthias




More information about the kde-core-devel mailing list