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…
Possibly related posts:
3 trackbacks
12 comments
> Here are Trolltech, we think the Glib main loop should be that mechanism”
“Here are Trolltech, we think the Glib main loop should be that mechanism”
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 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?
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.
Comments on this entry are closed.