Ars Technica used the following picture to show that it's working:
If there's anything that I'm excited about it's the fact that the initiative came from Mozilla guys not from an outside group. A few years back when Lars and I did the Qt Mozilla port one thing we've realized very quickly is that due to some politics and time constrains on our part there's no way we could maintain that code. We have been talking about it and one of the conclusions was that the port will not succeed unless it's started from within Mozilla itself. Like this port certainly has.
Unfortunately it's not writing code, it's making it work and maintaining it that are the difficult parts. All the articles saying that there's Qt Firefox are just wrong. Code has been written that might allow Qt Firefox to be usable at some point, but just looking at that screenshot shows there's tons of work to be done before that happens.
In general I just don't think that Qt and Mozilla are meant to be mixed. There's ton of duplication all over the place. Qt has a GUI language, Mozilla has a GUI language, Qt is a toolkit, Mozilla has its own toolkit, Qt has networking library, Mozilla has a networking library, Qt has a JS engine, Mozilla has a JS engine, Qt comes with QtWebKit, Mozilla comes with Mozilla... Unless there's some kind of a discussion about integrating those parts then, especially in embedded scenarios, that duplication is far from optimal. I also think that while Qt Firefox port coming from within Mozilla itself 3 years ago would have all Qt/KDE developers compiling it within minutes, that window has closed with the release of QtWebKit in Qt 4.4. Qt/KDE community already has engines they're committed to (Qt engineers have WebKit and KDE engineers either WebKit or KHTML) so the code won't get any community traction from Qt/KDE developers and Mozilla guys will be left having to maintain it themselves.
I think it's certainly a great effort but I doubt the code can get anywhere without support from Qt/KDE community and realistically when talking about web in the the Qt/KDE circles Gecko doesn't even enter the discussion. Not even getting into a discussion about code quality and familiarity with it, big reason for that is that for KDE bug-for-bug compatibility with OS X, despite Mozilla's greater market share, provides a lot more attractive proposition due to similarity of usage of web engines in both environments, e.g. Dashboard widget compatibility. So all in all, great project, just a little too late.
12 comments:
You forgot the other half of the development equation: Nokia.
Actually i'm a big fan of kde (just user, not dev, for now). But i've to say that khtml and webkit are good, but for now i can't use a browser like konqueror, not because it's bad, but because it lack just one thing that firefox has: addons.
As a web dev firefox has firebug, web developer, noscript, tamper data, html validator and adblock. I'd need just these to change stable from firefox to konqueror. and i hope that that day will come...
But until then i've to use firefox.. and a qt version would be very nice, so i've not to install the gtk library (which i use just for firefox)
(about konqueror and that extensions, there are a script block, but it's not comparable to noscript, it lacks a lot of features to became usable... the html validator request every time to the w3 site to check the code, instead the firefox html validator has the parser integrated in the plugin, so it works also without network, and show the errors/warnings in a pretty way.... the konqueror adblock miss a feature to auto update itself, and some other little features....firebug... i don't know if there is anything like that for konqueror, but it would be very nice to have.... the other two, web toolbar and tamper data, aren't so important)
You might want to double-check your facts. According to this interview with a Nokia employee the initiative was apparently Nokia's and they asked for help from Mozilla to flesh it out.
I agree with you that Mozilla does duplicate a lot of what the whole Qt-development libraries provide.
Probably Mozilla would be more maintainable, and be accessible to more hackers by sticking to more Qt and less of their self-cooked soup. And for sure the cross-platform idea would be easier to handle for them as well.
But users will certainly enjoy a Mozilla that integrates good/better into a KDE environment.
I think it's perfectly ok to build a Mozilla which uses as much of Qt as necessary for this. (but in the same time, also does not use Qt where they have their own libs for that. The Qt port at the end should be as easy to maintain as possible as well...)
That's why Qt is modular at the end.
Right now Mozilla links to QtGui, QtNetwork and QtCore.
My Kubuntu system has 18 /usr/lib/Qt*4.4.0 libs in total. Mozilla use 3 of them.
I hope soon we will see Kubuntu, Suse/KDE shipping a GTK-free Firefox, hopefully being able to make use of kwallet as well one day (being aware this work has not even started)
Anyway, I feel that soon some distros will seriously think about switching from Gnome/Gtk to Kde/Qt, for obvious reasons. A Qt Firefox will be certainly hugely welcomed in that case.
I started to kind of question the idea when I heard it works by porting Cairo to use Qt. :)
I don't think this needs the KDE community to help out, both Mozilla and Nokia have plenty of people on their payrolls to make it happen. As I understand it, its for mobile devices.
I'm working on Mozilla project and I'm a big fan of KDE (especially whole KDE4 effort).
I do agree that the support for QT comes late and I tend to believe that there was lack of interest from both partied - QT/KDE and Mozilla that led us to such long waiting.
But when you summarize the situation, I think you miss several important points here Zack.
1) Mozilla provides a custom, full user experience together with the browser. It's not something you can replace with another engine out of the box. With all my years spent on KDE I have never been able to use Konqueror. With my last year spent on MacOS, I still don't like Safari. And I'm probably not the only one of my kind, so Firefox in QT would be nice thing to have (if only to remove the GTK dependency)
2) Mozilla project overall has very sophisticated and long term goals stated in the Mozilla Manifesto. Gecko platform is not only a base of Firefox, but will be (together with Mozilla 2 effort probably) also a base for many other technologies, be it whatever will come up from Labs (think, Ubiquity, Weave, Aurora), whatever will come up from Mozilla Messaging effort and Mozilla Mobile.
Being able to easily launch that in QT environment is a win imo, and definitely worth noticing.
3) Gecko engine is, and will be pretty unique in terms of supported technologies. It's not a 1-1 pair for QT's technologies. When you speak about UI engine in QT you miss that Gecko supports XUL and XBL, and CSS, while QT provides CSS-like styling. You forgot to mention JavaScript 2.0 effort, RDF, MathML, JSON and several others. It may be another reason for someone to experiment.
4) There is a lot of work going on right now on Mozilla 2 project. It will support many new technologies and standards, and offer new ones (now sre if Ian still wants to standarize XBL2 through W3C, but I think he does).
In a nutshell, I think that Firefox QT may open a new land of possibilities for KDE people and for Mozilla people.
p.s. 5) It may be just me, but I'm really surprised to see your blogpost being a bit dispiriting and demotivating. Usually open source is about joy of chaotic experiments, surprising combinations of technologies from far away and surprising results. Your post sounds like "there's a *proper* way, it's good, you should not experiment in other directions. period.". It's not how we work usually, and definitely not how you work Zack :)
So, cheer up! Maybe one day you will want to try an extension for Firefox, or test the crazy UI from our Labs (http://labs.mozilla.com/2008/08/introducing-the-concept-series-call-for-participation/) and build some quick funny think on top of it, and you'll find it easier with Gecko on QT.
My reply is a little long so I decided to write a post of my own as a reply:
http://djdarkmanx.blogspot.com/2008/08/firefox-qt-duplication-or-something.html
Hello Zack,
I agree with you and I use Konqueror as my main web browser.
The problem is that more and more websites are not usable with Konqueror.
For example my webmail : my provider switched from a very very old interface to a new one (Zimbra) and it does not work with Konqueror...
On the most famous french website dedicated to movies (allocine.fr), I can't see videos with Konqueror.
For Deezer and Jiwa (flash crap... but a lot of choice for the music), Konqueror doesn't work.
So, that's a problem for me.
I prefer KHTML to Gecko... but I'm only forced to use Gecko for more and more websites :'(
@temet: QtWebKit has already solved that problem for us. Once the KPart for it is finished and Flash support enabled in Qt 4.5, we'll have bug-to-bug compatibility with Safari. It's kind of the point of the blog, that the niche a Qt version of Firefox could've filled a few years ago is already filled.
@temet and others
Please file bug reports against Konqueror so we can check if these things are fixed or not. There might not be much that can be done about the flash, since it is gecko-based-only on Linux, but someone might be able to work magic.
@anon #2
Those ideas about extensions are all very nice and concrete, putting them in bugzilla as wishlist items would be great.
Remember that developers don't have the time to test every webpage out there. And they're more likely to be fixing bugs and working on features than random web browsing. ;) They depend on you for bug reports. And screenshots, valid backtraces, etc.
> 3) Gecko engine is, and will be pretty unique in terms of supported technologies. It's not a 1-1 pair for QT's technologies. When you speak about UI engine in QT you miss that Gecko supports XUL and XBL, and CSS, while QT provides CSS-like styling. You forgot to mention JavaScript 2.0 effort, RDF, MathML, JSON and several others. It may be another reason for someone to experiment.
XUL and XBL: Okay, these are Gecko specific. KDE/Qt has Kommander. Someone tried once (KAXul), so it could be revived if enough interest existed.
CSS: QStyle, as far as I know, is real CSS, just styling C++ code and not a markup language. Also QtWebKit provides REAL CSS in the sense that it does mark up a web page.
RDF: A _lot_ of RDF work has been done as part of Soprano and Nepomuk.
MathML: Planned for QtWebKit, I believe.
JavaScript 2.0: QtScript could, in the future, be made to support JavaScript2.
JSON: JavaScript Object Notation that QtScript can parse, though that leaves security holes. Someone could always write a parser.
In other words, yes porting Gecko to Qt may bring us a few technologies that Qt itself does not have, but most of them Qt covers or could conceivable cover.
I agree that there is a lot of overlap between Qt and Gecko.
Post a Comment