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.)
32 Comments to “Well Isn’t That Qt”
- 1 Pingback on May 9th, 2008 at 3:09 am
- 2 Pingback on Aug 7th, 2008 at 1:11 am
- 3 Pingback on Aug 8th, 2008 at 12:12 am
- 4 Pingback on Aug 10th, 2008 at 2:25 pm
- 5 Pingback on Aug 10th, 2008 at 2:30 pm
- 6 Pingback on Aug 20th, 2008 at 3:31 am
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!
I just built with QT and its important that you disable printing as per vladimir’s instructions above!
The end result was interesting… far from usable though. File dialogs didn’t seem to work for me and when I tried to enter text into the form on the Mozilla Minefield site, Firefox seg faulted.
I’m really excited that work is being done to bring QT to Firefox, as I really enjoy working in KDE and would love things to be at least a bit more seamless. I hope that work on this continues and that we have a QT option for firefox soon.
This is fantastic news! Please keep up the good work. KDE 4.1 with a well integrated Firefox would be a very very very nice combo!!!
Good news !
Hope this Qt-port attempt won’t be dropped like the previous attempts !
Firefox under kde has always has a pain for me. One of the main reason why I use kde is that I can’t stand the gnome system dialogs (eg: file selector dialogs) and also because I always had the feeling that the gtk UI was less responsive when you switch fast from a menu to another, or when switching tabs, … (I guess just a few milliseconds slower but I can feel it and I don’t like it) But the problem is that the web browser is the application I use most (like most people do) so it makes my kde experience less enjoyable that it could be.
I’ve just switched to FF3 under kubuntu and I was very disappointed because it’s so slooooow. Eg: switching tabs takes half a second to proceed on a dual core 2.4Ghz. On the same computer, even under the bloated windows vista, the UI feeling is quite faster. (try to play with http://www.iwidgets.com under kubuntu default settings and you’ll see what I mean)
Then I tried to disable the kubuntu’s option : “Use my KDE style in GTK applications” and I choosed a gtk theme instead. Now FF3 is damn ugly, but it’s faster and more responsive. It is not as fast as the windows version but I can now use it without being as frustrated as I was before (except for the bad look and the file selector and print dialogs). I tried the official build of FF3 but I can’t feel any difference.
I really hope that we’ll see a fully working QT-build in the future !
Correct me if I’m wrong but I thought that QT4 was now available on windows, linux and macosx with open source license, so I guess that it makes the perfect choice in order to lower the differences between the development branches !? If true, I wonder why there not much interest around a QT build for firefox.
Does this mean that we can have a QT-based XUL runner?
Even if you don’t switch to QT for official Firefox or XUL releases, this is pretty good news.
“Correct me if I’m wrong but I thought that QT4 was now available on windows, linux and macosx with open source license, so I guess that it makes the perfect choice in order to lower the differences between the development branches !? If true, I wonder why there not much interest around a QT build for firefox.”
wow this will make KDE4 experience make smooth. Personally I hate few GTK widgets (apparently there are no alternatives for them).QT is the better toolkit but License is not very friendly as the case with GTK. So If somebody wants to build commercial product out of Firefox-QT he have to pay troll tech. Not the case with WxWindows or GTK.
This is the primary reason why majority of commercial and Open Source project goes with GTK or WxWindows and not QT.
Lets hope that the scenario will change.
was trying to build from hg branch. went ok until cairo-qpainter-surface.cpp. and the build stops there with lots of error messages ;(
guess i need to update the source later and retry.
Using gcc 4.3.1, I get “widget/src/qt/nsWindow.h:354: error: multiple parameters named ‘aEvent’ ” . Using gcc 4.2 works around it… please fix soon.
> Firefox under kde has always has a pain for me. One of the main reason why I use kde is that I can’t stand the > gnome system dialogs (eg: file selector dialogs)
about:config has the option ui.allow_platform_file_picker, and if the boolean is toggled (to false) you get KDE’s file requester (when running KDE at least). Why isn’t that a default? KDE-people probably want that. Good to see a QT-version though.
Very exciting, like other would love better KDE integration!
I downloaded the x86 binary (http://timeless.justdave.net/maemo/firefoxqt3.tar.gz) but I would rather not install it globally on my KUbuntu :) is there a way to run it from a local directory?
Thank you for your efforts,
Lindsay
Why OSX and win32 ?
I thought that QT used the platform native toolkit under the cover. So porting to QT would obviate the need to maintain those two additional platforms, wouldn’t it ?
wow, Firefox in QT?! i hope this blends well with KDE. i just hate to look @ Firefox in GTK but have no choice since this is the best web browser out there. the file dialogs look odd and out of place. it (file dialogs) makes a modern KDE 4 desktop look old!
hope this takes off well .. .
Using gcc 4.3.0 I get the same error as the previous commenter.
@kucrut: add “#include ” to the file gfx/cairo/cairo/src/cairo-qpainter-surface.cpp and try again.
And a third time, using square brackets instead of angle brackets: “#include [memory]“. (Fix your comment system dude!)
The build issues raised by kucrut and G2g591 above are fixed by the patch attached to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=449566
I hope it will be stable soon, I always dislike using Firefox on KDE. It just don’t integrate well. When this happens the desktop will one step closer to perfection.
I hope that Thunderbird will use this qt framework also in the future.
Hi there,
Just wanted to know if there is something new about the port to qt? Are you still working on it? Never heard of it after this announcement. That doesn’t really mean something good, right?