Note: This is my first blog posting ever, so please bear with me. 
There has been quite some talk recently at Trolltech about how well Qt “fits” together with other software components on the X11 desktop. We do a fairly good job of it already by providing the QAbstractEventDispatcher API in Qt 4. This has allowed people to plug Qt into the Glib main loop fairly easily, resulting in an application that can use any of the Qt, GTK+, KDE, and GNOME APIs. This is quite powerful, but has one significant drawback: if your application is designed to allow third-party extensions (i.e. plugins), you have to know in advance what kinds of integration to provide. Consider a Qt application tries to load multiple plugins, where each plugin uses GTK+. If the Qt application did not provide some sort of integration into the Glib main loop, what happens when each of the plugins tries to? I have the solution… 
Yesterday, I got Qt running on top of the Glib main loop. By using the QAbstractEventDispatcher API, I was able to completely replace the entire event dispatching mechanism of a Qt 4 application with less than 600 lines of code. What does this mean? No integration; the scenario above is now possible, since Qt would already be running a Glib main loop. I can now write an extension to my programs with any toolkit I want. Even more attractive is the idea that I can now write a Qt based extension to any GTK+ or GNOME program. Just think… I could write a plugin for the GIMP or for Eclipse, I could use the asynchronous GNOME VFS API. I’m sure there are possibilities I haven’t even thought of yet. And that’s the whole point: the possibilities are endless.
Of course, this is all useless if only I can do it. I envision applications and frameworks in the future that give Qt, GTK+, KDE, and GNOME programmers the same flexibility that Windows programmers get with COM and ActiveX. I’ve talked with Matthias (mostly to brag about what I had done), and he was very interested in getting this code into Qt, possibly as soon as Qt 4.2. We both agree: the ideal would be for all applications on the X11 desktop to use the same event dispatching mechanism. Here are Trolltech, we think the Glib main loop should be that mechanism…
15 Responses to “Qt and Glib”
> Here are Trolltech, we think the Glib main loop should be that mechanism”¦
What?!
Why not try to get the qt main loop into glib 3.0?
“Here are Trolltech, we think the Glib main loop should be that mechanism”¦”
That remark sounds like flamebait to me! Watch out…
Does this mean that the integration could go the other way around? For instance, could one compile The GIMP to use the KDE file picker instead of the weirdo GNOME one?
Very nice, when this is in Qt 4.2 will give me more bragging rights about how awesome Qt is to my mates 
This would be a really powerful option to have.
[…] I wonder if this will hit trunk/ of the Qt codebase. I seriously think this kind of thing is absolutely required in order to move forward and let developers take maximum advantage of their skills. […]
I just blogged about this on my blog. Sadly, your blog seems not to support Pingbacks. Please enable them.
Hey that’s cool! I hope it makes it into 4.2..
But just clear something for me, does it mean that Qt would depend on Glib, or am I just thinking nonesense?
[…] Brad Hards of Trolltech says that future versions of Qt4 (perhaps as soon as Qt4.2) will start using the Glib event dispatch loop. This is downright wonderful news for a couple of reasons. The technical reason is that you will be able to use binary Qt4 plugins in Glib/Gtk apps and vice versa — so you would be able to use both GnomeVFS in KDE, kioslaves in Gnome, Arthur canvas in The Gimp, integrate Filelight with Nautilus… The fact is, on the Linux desktop, some Gtk/Gnome and Qt/KDE duplicate a lot of work. Sometimes the way KDE does something is better, sometimes the way Gnome does it is better. With the new event dispatcher, KDE4 and future Gnome apps will be a lot more free to call each others’ APIs. […]
Thats actually really cool.
Is there any performance issues with using glib? It seems to me that some extra hackery would have to go into glib to get the most out of its interaction with Qt.
Just a rambling though, I haven’t dug through glib or Qt at all 
Either way this is pretty darn neat, and I look forward to see what the devs can pull out of their hats with this trick.
Will this mean that Qt and KDE will break everything GNOME releases a new Glib? It’s already a pain in the butt when a minor bump in the Glib version causes me to rebuild everything starting with a ‘G’, I think I might go postal if I had to rebuild everything with a ‘K’ as well.
Sweet, now I guess the only big hurdle would be getting identical themes/behaviour for both QT and GTK+ so that an app/desktop would be completely seamless?
“I envision applications and frameworks in the future that give Qt, GTK+, KDE, and GNOME programmers the same flexibility that Windows programmers get with COM and ActiveX.”
I suggest you give the above programmers the same performace that Windows programmers get, and only after that the flexibility, because recently all my attempts to use Linux end up with the same conclusion: KDE is slow as hell! GNOME is slow as hell! It turns out (in my experince) that often a software that is made on pupose to run slow (to sell hardware) runs faster than open software. I can’t understand what’s the matter. Am I the only one to notice that the major and most usable desktop enviroments for Linux are so damn slow?
Why you have choose glib main loop as main dispatching mechanism?
Hi! I’m very interested on this topic and have done some good research about it. Since I’m in the audio development community, having a way to do standard plugins that can instance interfaces without having to resort to really bad hacks (such as core/UI separation via IPC) etc has been a very needed goal. If you are interested (and since you dont provide any means of contacting you directly) please drop me an email.
Cheers!
“Am I the only one to notice that the major and most usable desktop enviroments for Linux are so damn slow?”
Yep.
[…] “Yesterday, I got Qt running on top of the Glib main loop. By using the QAbstractEventDispatcher API, I was able to completely replace the entire event dispatching mechanism of a Qt 4 application with less than 600 lines of code. What does this mean?” […]