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