I and a few others have been poking at our widget layer for the past few weeks, looking at adding Qt support. There was an earlier attempt at a Qt backend, but it never really got maintained, and there wasn’t much interest in it back then. Recently, though, Qt has made great strides on embedded devices and with support for advanced graphics architectures (such as support for OpenGL and DirectX rendering), and might be a great way for us to get a feel for some of the problems we’ll face in the future when we try to integrate 3D-accelerated rendering into Gecko. Folks at Nokia have contributed much of this code, since they’re interested in experimenting with Qt as well. We’ve got the initial work available on a hg branch (off mozilla-central; our first experiment on big-project branches in the future hg world).
I’ve had a great time working with Qt so far; it seems like a well-designed modern toolkit. There are a few quirks; most notably, the pieces that Gecko/Cairo needs to render text aren’t really there, but on the whole the integration is pretty good. The big text piece that’s missing is a drawGlyphs method on QPainter — something that would take a QFont and an array of glyphs and positions. Additionally, methods to go from a string to an array of glyph indices/positions for a given QFont would also be helpful (though most of our font backend here is using FreeType directly, so we can obtain glyph indices directly). In the QPainter Cairo backend that I wrote, I kind of cheat on this issue under X11 — I grab the X Drawable and pass on the show_glyphs work down to a wrapper xlib surface… but that doesn’t work for Qt Embedded. Anyone out there who knows Qt innards well want to implement this?
There are a few other minor annoyances with QPainter; Cairo’s rendering code does a pretty good job of letting operations be specified in a general way (e.g. everything with paths), and it does whatever optimizations are possible internally (e.g. converting a rectangular path to a rectangle for clipping/painting purposes). QPainter doesn’t seem to have these optimizations for the general path methods, so the QPainter backend has to do a bunch of extra work to detect this case to call the faster filling functions. Similar optimizations are missed for brushes — filling with a tiled pixmap QBrush is slower than calling drawTiledPixamp, even without transforms. The Cairo backend tries to handle these cases, but there’s more that needs to be done.
Overall, though, what’s on the Qt branch now works pretty well under X11; under Qt Embedded, there are some problems with text rendering mentioned above, but things are in good shape otherwise. I hope that in the future that the Qt port will be a toplevel supported Gecko port, alongside gtk2, Win32, and OSX, but there’s still a bunch of work needed to make that happen. If anyone’s interested in helping out, drop in to #gfx on mozilla irc!
(Note that there aren’t any plans on switching away from gtk2 for our official Linux/X11 builds; gtk2 will remain the default supported toolkit there.)