NOV
3
2009

Firefox KDE Integration

Now that the mention of the Firefox KDE integration I've done has reached also the dot, I guess it's time for a couple of things that don't quite fit into an article but I should probably say them somewhere anyway.

First of all, this is nothing against Konqueror. I still use Konqueror. In fact when a couple of months back there was a wave of "let's ditch Konqueror" voices on the planet and kde-core-devel, I was one of the people opposing that (and I still think it's not an option, as Konqueror is still the best KDE browser there is - Aurora is Qt-only, Rekonq is at version 0.<somesmallnumber>). For the next openSUSE release we will evaluate the possibilities again and Konqy may end up as the default again if it's considered to be up to the job. Speaking of which, Konqueror has never really been 100% default in openSUSE, as the desktop icon, which is what the common user uses, has always been Firefox, so we can also say the we just fixed the inconsistency (and it's really simple to switch it back). But the real reason was that many people are simply not satisfied with Konqueror, so we decided to try to not ignore the reality for a change. I myself use Konqueror, but if somebody else wants to browse the net on my home machine, they get Firefox. I don't like this, but what the hell, c'est la vie.

So, when we decided to make Firefox the default, we also faced the problem that we switched to something that from KDE user's point of view sucked in pretty much all aspects except for the browsing itself. The idea of Firefox desktop integration on Unix ranges from not bothering with it at all, over using generic not-really-desktop stuff like mailcap, to thinking Unix==GNOME. Normal Firefox in KDE offers to open PDF files with Evince, shows /usr/bin in a filedialog when you decide you'd like to open the PDF in some other application, has inconsistent (not just reversed) button order in dialogs and other yummy things. There have been attempts to solve this e.g. by creating a Qt version of Firefox, but those AFAIK have never led to something usable in practice, and with WebKit now part of Qt I somehow fail to see the motivation for anybody to try once more. And in this situation we had just a short time before openSUSE 11.2 feature freeze.

The trick, of course, was using magic. The Firefox with KDE integration is still the same Gtk Firefox, just with a bunch of hooks calling an external helper. I don't have the ability of some other KDE developers to have clones, and I'm not crazy enough to try to mix Gtk and Qt in one process (which, despite the possibility of a shared event loop, should be nowhere near trivial). So it's nowhere near the extent of the Qt port, and maybe that's why it has worked out (as we all should know, perfect is the enemy of good).

The helper and the patches at available in a Gitorious repository, they are made to match the openSUSE package so they may not possibly apply cleanly to upstream sources, but feel free to play with it. Actually, you are more than welcome to do anything you want with it (wanna be the maintainer of it? no problem). With the problem more or less solved, and with other things to do, I don't have any further big plans for it. I will try to push this upstream if possible (I have no idea what faces will Firefox developers make when they see it), but besides that, there are still many other areas that need some magic. And, after all, the ultimate plan is still that Konqy will one day rule the world ;).

Comments

Are there any plans to make the webkit kpart stable? It would make Konqueror the best browser.


By groszdani at Tue, 11/03/2009 - 23:23

The kdewebkit classes (Page, View) are in kdereview pending a move to kdelibs, and there was a lively debate on kde-core-devel@ to improve them. The KPart is still in playground, I expect pending the above classes maturing.


By Will Stephenson at Wed, 11/04/2009 - 07:32

I'm using webkitkde-svn and it works great... More stable thant khtml part.


By Cédric Bellegarde at Wed, 11/04/2009 - 07:19

After reading https://bugzilla.mozilla.org/show_bug.cgi?id=140751 at least one Mozilla person knows about this patch :-)


By kamikazow at Wed, 11/04/2009 - 15:24

I wish someone would do something similar for Chromium

I've tried Arora and reKonq but neither come close to Chromium for speed, stability and compatibility

I've never been very impressed with Konqueror even back in the 3.x days, it tries to be a Jack of all trades but just doesn't cut it as a decent web browser


By Michael Lothian at Wed, 11/04/2009 - 16:44

Nokia submitted code to the Mozilla trunk for a Qt 4 based Firefox. I just haven't seen anyone else build it.

I'd love to see it to test it out however.


By enderandrew at Wed, 11/04/2009 - 21:07

Qt Firefox appears to be very dee-ee-aye-dee. No interesting change for quite some time. And no big wonder, who'd really bother with a Qt Gecko port now when there's QtWebKit?


By Lubos Lunak at Thu, 11/05/2009 - 15:26

Very nice! Does this mean that Firefox will stop opening directories with nautilus (and not at all when there is no nautilus) and instead use dolphin? I hope this will be applied in Fedora as well (I'm a Fedora user). Actually I don't get why FIrefox even bothers with what application to use to open a certain file. Why not just always use xdg-open? This always worked for me. Then under GNOME the GNOME apps are used and under KDE the KDE apps!


By Mathias Panzenböck at Fri, 11/06/2009 - 03:22

The only problem with Konqueror is KHTML and the integration of Gwenview is a bit heavy when other browsers display images (scaled) so elegantly.

I haven't used Firefox since discovering the browser not mentioned here - Chromium, it is almost perfect for me as it is really fast (loading from cold I mean), It draws up almost everything perfectly and very quickly, The UI is so very minimal but fully functional. It picks the correct KDE action for everything (file picker isn't as good as the KDE one). If efforts are to be made on anything then I think the future is Chromium once it has stabilised because even in its current state it is still the best browser on Linux.


By behavedave at Fri, 11/06/2009 - 10:09

"I'm not crazy enough to try to mix Gtk and Qt in one process (which, despite the possibility of a shared event loop, should be nowhere near trivial)"

Is it really that hard? As Qt has Gtk+ filechoosers on Gnome, why wouldn't it work the other way round?


By nf2 at Fri, 11/06/2009 - 20:14