Developers from Nokia and Mozilla have been working hard to port the Mozilla Platform and Firefox to Qt and there are now some solid results available. An experimental build of Firefox Qt is available, and you can download the sources from Mozilla's mercurial repository. The plan is to merge the Qt branch into the central Mozilla branch to make the port official. KDE Dot News spoke to developer Oleg Romaxa from Nokia who came to Akademy 2008 from Finland.
Why did you do this port?
Because we were going to make Maemo use Qt in the future and we were making a browser based on Mozilla for the N810, so now we are making this new browser version based on Qt. Before, there was no Qt port available for Mozilla. It only took us 5 days to port it. We asked for help from Mozilla and they sent a team to Finland for a week.
What's the current state of the port?
The Qt port is mostly ready now for our browser. For full Firefox support, we need to implement XUL widgets, theming, and make some implementation for Flash player (NPAPI) support: it works but doesn't currently draw anything.
Will this be supported in future?
Yes, we will support it. We will cooperate with Trolltech to ensure it continues to be supported.
What is Mozilla's interest in this?
Mozilla are interested in mobile devices. Nokia make mobile devices, and will be using Qt. If you look at the mobile Firefox requirements, Qt support is in that.
Why are Nokia now developing two browsers? This one and QtWebKit?
Nokia will use the best browser for the job. Currently, we cannot make a full-featured and integrated browser with WebKit in mobile. But with Mozilla, we do not need to do anything, we can take existing models and API's which are available. Also, NPAPI support is already in the Gecko web rendering engine. They are also concerned that WebKit is to some extent controlled by Apple, who are in competition to Nokia with their iPhone.
What are you hoping to get out of Akademy?
I'm hoping to find people and ask them what they think about the Qt port and having Mozilla integrated into KDE. So far people are just talking about WebKit.
Will distributions package it?
That would be interesting to know. Maybe Kubuntu would like to have it...
Also, i've heard of Russian companies making KDE-based distributions and they might be interested in having Firefox without having GTK installed.
Do you think Mozilla will get rid of GTK?
No, Mozilla will support officially only the ports they have a particular interest in. If it helps to expand their market they will be more interested.
Where can people find more information?
There is a branch available on Mozilla's Mercurial repository. http://hg.mozilla.org/users/romaxa_gmail.com/index.cgi/mozilla-qt/ is the latest branch, it should soon be merged when I fix a final outstanding bug.
What needed doing for the port?
We ported Cairo to gain a QPainter backend. It's not full-featured, but it's enough for a web browser. Qt's implementation of the Cairo backend is much simpler than with GTK, because Qt is better able to integrate graphics and widgets.
Can the Cairo backend be used for other Cairo applications, like swfdec?
I'm sure it's already possible to do most of what's needed, images and compositing are there. It's not fully implemented but it's mostly complete. We are talking to Cairo developers to push the Qt backend into the Cairo source tree.
Comments
It is interesting to read that this time around, there is cooperation from Mozilla for a porting effort. If I remember correctly, this is where previous efforts have failed in the past. I hope this will develop into a viable alternative rendering engine. It would be good to be back in the old days where you could switch your rendering engine in Konqueror between the Mozilla engine and KHTML. Maybe this time around, we will have three options?
Yes, I really hope this gets developed and refined to the point where we have a Mozilla Firefox KPart. It would be just lovely to be able to switch back and forth between the KHTML KPart and the Firefox KPart for displaying pages in Konqueror.
Even lovelier if the Firefox KPart would interact properly with its container to switch to a different KPart depending on the content type of a clicked link. I love having text files come up in Konqueror using the Embedded Advanced Text Editor KPart. And having URLs passed to the appropriate KIO-aware applications like KPDF based on content type. KDE really got it right with KIO and KParts, and that is the main reason why I use Konqueror as my primary browser. Every other browser, Firefox included, seems awfully primitive with its treatment of content types and helper applications.
Hi
all news around is about Webkit...but i really want to know whats happenning on khtml side.how is the SVG stuff going? was that bytecode interpreter got merged into trunk/? what happened to WYSIWYG editors support, etc...
Yes, what is going on the KHTML?
KHTML is going to have a hard time trying to keep up if they want to continue a completely separate development. A more practical and viable approach would be trying to port whatever improvements are unique in KHTML to the current QtWebKit. I imagine several obstacles will need to be overcome if this is to happen, not the smallest of them being the NIH syndrome. OTOH consider the fact that the more WebKit code does not belong to Apple or TT/Nokia the freer the resulting library will be.
Another option: port whatever improvements are unique in WebKit to KHTML. The resulting library will be even freer.
1) how is the SVG stuff going?
Very well.
2) was that bytecode interpreter got merged into trunk/?
The initial version is in KDE 4.1, and is a nice improvement
over KJS4.0.x
3) what happened to WYSIWYG editors support
The basic version is in KDE 4.1 --- the fundamentals work,
but the command set support is somewhat limited.
Are you not surprised that you get this kind of questions?
Normally every project tries to tell the users at least a little bit what the current state is, but KHTML does nothing like it - not at all.
Heck, there are enough bloggers out there who would love to bring news about KHTML to the masses, but no, the KHTML project doesn't publish any information, it could... well, do something. I honestly don't understand the reason behind that. It's just sad :(
http://vtokarev.wordpress.com/
Is the developer's blog for the current SVG SoC project.
Frostbyte was actually announced in SadEagle's blog.
Where else would you like? I'm curious.
That are amazing news! Will it be possible to use existing Firefox addons with the Qt version? That would be a real killer feature for a Qt based Firefox Browser in KDE.
No reason why not - extensions are just interpreted, XUL-ly code :)
Yes, extensions work flawlessly.
Plugins like Flash on the other hand crach Firefox-Qt in it's current state, but that's pre-alpha software for ya. ;-)
s/crach/crash
blargh.
By pre-alpha software, do you mean Flash? :-)
Nope, Firefox.
Flash 10 is actually release candidate now.
Flash 9, well, eww.
This is great! I think that Firefox is the only GTK+ application on my system, so this will be VERY welcomed :D
You should install Gimp and Inkscape. They are still much better then Krita and Karbon14.
The interface of Gimp drives me up the wall. I can't draw so I don't use Inkscape, but I find Krita and Digikam take care of all my image manipulation/editing needs just fine.
Gimp and Krita really aren't any more comparable than Kate and KWord. Sure, Kate and KWord are both text editors, but beyond that the target audiances are pretty much unrelated.
Gimp, like Photoshop, is much more so meant to be photo-manipulation software first and foremost (hence the name for both), although it is frequently abused to create images. Krita, like Corel Painter, is intended much more so far artists wanting to paint pictures (not to manipulate photos).
Of course, you're also assuming that he actually wants to use *any* of those programs.
Great to hear. Firefox has always seemed out of place, and this was possibly top of my wishlist for... all software really.
Nice to see it's coming along well, hope it's all finished soon - default in Intrepid maybe?
Perfect way to polish up KDE 4.1.
What I would really like to see is something as the awesome bar integrated with nepomuk. Either an awesome bar in konqueror with nepomuk integration or integrating the awesome bar of firefox with KDE and make it use nepomuk would be great.
Imagine, for example, opening krunner and start typing the tag of one of your bookmarked sites, then krunner does its magic, you click enter and you have your web browser opening the page that you want.
That would be.. umm.. awesome :-) What bothers me about most web browsers is that they do not use the system stores for bookmarks, certificates, history, et cetera, so you end up with lots of silos of data. Hopefully nepomuk integration can go some way to remedying it.
This is WONDERFUL! Imagine Firefox integrating perfectly with the KDE4 Oxygen style! Most importantly: ARE THEY GOING TO FIX THE FILE > SAVE DIALOG??? The darn GTK file open/save dialog has bugged me for ages. I've always been mad that Firefox doesn't detect the DE and show the KDE file dialog on KDE desktops. (I guess I could say the same for the GIMP, but the GTK+ *is* "The GIMP Toolkit" so I figure they have a right to promote it. ;-)
I could imagine some other useful things coming from a more KDE-centric Firefox, such as using kuiserver for downloads (http://pindablog.wordpress.com/2008/07/24/more-on-kuiserver-and-extenders/), and using Nepomuk to store bookmarks. That would be so nice. Thank you Nokia, for starting this!
Actually it still doesn't use the KDE file dialog. It uses the Qt one.
...but at least it isn't the Gnome one. :P
...and starting with KDE 4.1, Qt apps will use the KDE dialog (unless they use some special functions).
Currently, Firefox-Qt displays the Qt file dialog, as does several other Qt apps I tried. In fact, it only seemed to use the KDE file dialog with Qt Designer.
I'd love that!
That only works if the app links kdelibs and is a KApplication, as it's KDE overriding QFileDialog's static functions, not Qt loading KDE's KFileDialog by itself.
i hate the gtk and qt file dialogs too. For a long time I used this to get kde file dialogs from gtk apps such as firefox:
http://www.kde-apps.org/content/show.php?content=36077
My open/save dialogues look ok, but are missing the "Places" section down the side - so say I'm trying to attach a file from a USB stick, I have to copy it into my home directory first, very irritating. I would love to see full native Dolphin-style dialogues.
There's a neat trick available in Firefox:
Enter about:config in the location bar, then search for 'ui.allow_platform_file_picker' and set it to false.
Restart Firefox and voila. It's not the KDE dialog, but it's better than the GTK crap.
Works and makes ff much more usuable.
Wow, thanks. It's basic, but at least has some usefullness rather than the default.
Yeah, the "built-in" file picker (which results from setting that pref to "false") was written by a mozilla bigshot (asa) who agrees with us that GtkFileChooser looks like ass, and lacks important capabilities (e.g., precise modified TIMES instead of just dates, and a column). But you can get exactly what you want (the KDE 3.5.x filepicker, WITH BOOKMARKS AND ALL CONTROLS) if you're still back on 3.5.x:
Just Use the kgtk2-wrapper to intercept and "fix" the file chooser calls. Anywhere Firefox would normally use GtkFileChooser, you get the KDE panel! With a usable filesize column, all of your bookmarks (and the ability to create more of them), the works! Just run it like this:
/usr/bin/kgtk2-wrapper firefox
Most distros have prebuilt kgtk2-wrapper for you, in some "kde addons" type of package. Just install it. If you liked You're gonna LOVE IT!
And of course, if you use Thunderbird too, just do this:
/usr/bin/kgtk2-wrapper thunderbird
I haven't tried wrapping GIMP, but I suspect that it would work too.
KDE does have a Gimp-like drawing program: Krita.
It has a cleaner layout. What has always bothered me about Gimp is the lack of a "Line" tool. *shrugs*
Keep up your hard work, mozilla team.
*click* shift *second clock* voila
KDE does have a Gimp-like drawing program: Krita
Actually, neither The GIMP or Krita is a drawing program. They are paint programs. A drawing program normally supports some sort of vector file format. So, Karbon14 is a drawing program. It would be nice if the same program could do both painting and drawing AND support both vector and raster output files.
Of course Krita can do that. We're talking about a part of KOffice here. It can even do music notation, wordprocessing or work with an (interactive!) worldmap... There is nothing Karbon14 can do and Krita can't, just like there is nothing Krita can do and KWord can't. It's just the interfaces are optimized for their respective tasks. Below, it's one system.
All aboard the pedantic train!
No seriously, you can't just say "drawing means this, painting means that"... you don't own the English language, so stop telling me what to say.
I'm sorry about this post, but pedantic stuff like this really gets me going.
If you try to use Krita you will see that there is a lot of space for improvements. Until Krita is ready I'll use Gimp, because it's the best free Image-Manipulating-Program.
I'll let you in on a little secret: software is never ready. There's always a lot of space for improvements.
You are right, but at some point the software is "ready" to use. And Krita isn't at that point, jet.
Photoshop must be the one exception.
I've never really heard someone say that Photoshop is missing crucial features they need. In fact, Photoshop is too powerful to the extent that Adobe has been talking about seriously trimming down Photoshop and making future versions simpler for the average user, while continuing to support CS3 for professionals.
Given the fact that Nokia in the last period has done a lot of "shopping" I will not be surprised to read of such an acquisition.
We will see. Maybe it depends from the result of this porting.
Uhh, no. The Mozilla Foundation is a non-profit, isn't for sale, and a completely different different mission and goals than Nokia.
The Mozilla Foundation is non-profit, but the Mozilla Corporation *is* for-profit (they created it for that entire reason). The Mozilla Corporation was created in 2005 as a subsidiary of the Foundation, IIRC.
Though I gotta agree that it doesn't seem very likely, theres a sight overlap but not close to as much as Nokia and TT.
Yes sure, an eventual Mozilla acquisition is another matter than the TT ones.
But still there are some good reasons to do it:
Nokia's new strategy is heavily based on internet services (http://www.ovi.com) and the convergence between the desktop and the mobile devices.
The browser is a fundamental piece of software to access those services.
On Mozilla labs are developing technologies to better integrate web services on the browser (http://labs.mozilla.com/projects/weave/) and hence on the device that runs it.
Otherwise if Nokia isn't interested in Firefox why it's working hard to port FF to Qt? While at the same time if it is interested in FF while not acquire Mozilla given the fact that has acquired everything else (Symbian, TT, a number of social site)?
I'm not an expert on acquisitions, but Nokia has recently bought the whole Symbian (something) and made the Symbian Foundation (fully owned by Nokia). So I'm really curious to know if there is some legal reason why can't Nokia do the same with Mozilla corp and/or foundation in a way or in another to suite their desire to control everything related to its business.
Nokia is clearly interested in Mozilla otherwise they wouldn't have created the Qt port. I don't think we'll ever see Nokia buy Mozilla - they don't need to buy them to influence Mozilla as can be seen from this Qt port. If they need something to be supported, they simply need to code it.
Why did you do this port?
Because we were going to make Maemo use Qt in the future and we were making a browser based on Mozilla for the N810, so now we are making this new browser version based on Qt.
Sounds like they are going to base Maemo on Qt in the future. If that is true, I would consider getting one.