Well Isn’t That Qt
Published by vladimir May 6th, 2008 in MozillaI 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.)
Wow. Are you a) Using Cairo’s fallback rendering to to draw bits to a QPainter b) Implementing a full Cairo back-end that calls Qt’s rendering engine primitives (Arthur) c) Implementing a Qt back-end under the Thebes graphics layer d) Any two of a-c) plus e) through g) :-) ?
Are you aware of the “Qt example in cairo-demo” thread conversaions that took place in 2005? I’m not sure if anything concrete came out of that.
The Cairo backend uses QPainter to draw everything (which, afaik, is the public interface to Arthur). Cairo’s software rasterizer isn’t involved. Other than the glyphs, I forgot one more piece — QPainter can’t do arbitrary path clipping with antialiasing, which is a little painful.
Heya!
Did you perchance try to contact any Troll — I’m thinking Thiago Macieira in particular — to discuss your project and your issues with QPainter? I have an idea they would be happy to talk with you, and perhaps even consider adding facilities in QPainter to make your intended goal easier to reach, who knows. :)
Hello !
How can i build this branch, i have try with the official documentaion in the website but i obtain this error :
make[1]: *** No rule to make target `/home/loic/apps/mozilla-qt/nsprpub/configure.in’, needed by `/home/loic/apps/mozilla-qt/nsprpub/configure’. Stop.
Other question : Is there an option to select the qt-backend ?
Thanks !
Would this allow Firefox to blend in better on a KDE system?
Yes !
Her is the bug report i have wrote for the kubuntu one :
https://bugs.launchpad.net/bugs/193538
> make[1]: *** No rule to make target `/home/loic/apps/mozilla-qt/nsprpub/configure.in’, needed by `/home/loic/apps/mozilla-qt/nsprpub/configure’. Stop.
There are missing nspr and nss, see:
http://developer.mozilla.org/en/docs/Mercurial#Checking_out
> Is there an option to select the qt-backend ?
I guess ./configure –help should works…
“cairo-qt” - is new toolkit.
thanks !
there is an error during compilation with the printingui component
i have to edit
/home/loic/apps/mozilla-qt/embedding/components/printingui/src/Makefile.in
to add ‘qt’ in this line
ifneq (,$(filter gtk2 qt photon beos,$(MOZ_WIDGET_TOOLKIT)))
PLATFORM_DIR = unixshared
endif
to have PLATFORM_DIR initialized.
However i have an other error just after with :
/home/loic/apps/mozilla-qt/embedding/components/printingui/src/unixshared/nsPrintingPromptService.cpp:47:35: error: nsIPrintDialogService.h: No such file or directory
how can i fix this ?
Thanks !
Add –disable-printing, –disable-javaxpcom, –disable-installer to your mozconfig; printing stuff isn’t hooked up.
@Matt
Yes, it will.
@vladimir
I totally agree with S.; this is a great news both for Qt and for KDE, maybe you would find some more help to maintain your work by contacting some Qt/KDE Developers!