My Little Blog

May 23, 2010

KDE’s WebKit browser Rekonq gets extension support

Filed under: Uncategorized — kmi @ 22:31

Sometimes pretty cool things happen and yet almost nobody knows about them.
One of the coolest things I came to learn recently is the development of extension support in rekonq.

The development is done by Nikhil Marathe. He’s implementing Chrome’s extension API which is luckily based on HTML, JavaScript and other web standards which makes it easier to adopt than Mozilla’s current XUL-based model (which is being deprecated my Mozilla in favor of Jetpack in Firefox 4.0 anyway).

Kudos to Nikhil for his awesome work!

In related news, from what I’ve read rekonq 0.5 is shaping up nicely. According to the roadmap all targeted features are done which hopefully means that the release target in June is hit.
Rekonq will (at least if nothing unexpected happens) also become the default browser of Kubuntu 10.10. It’s already default in nice Arch-based distro Chakra.
Now only Fedora 14 KDE and openSUSE 12.0 need to follow. πŸ˜€


  1. could you clarify if konqueror is a dependency for rekonq?
    I dont know why in Arch linux reqonq pulls in konqueror as dependency

    Comment by Venky80 — May 24, 2010 @ 00:08

    • Rekonq uses some of Konqueror’s preference panes (like cookie management). If a distributor wants to properly support Rekonq, he needs to split the Konqueror package into Konqueror itself on one hand and on the other hand support modules (like the pref panes) into a separate package on which Rekonq can depend.

      Comment by Markus — May 24, 2010 @ 08:09

  2. neat. πŸ™‚

    but does it have crash recovery yet? I can crash *anything*, and often have a lot of tabs.

    venky80: probably some shared config dialogs or something? iirc folderview had to depend on something in konq too… maybe those things could be factored out someday.

    Comment by Chani — May 24, 2010 @ 00:13

    • Crash recovery can be activated in the settings:
      The options is called “Restore Last Opened Tabs” in the “When starting rekonq:” field

      Comment by pano — May 24, 2010 @ 01:14

  3. @Kamikazow: πŸ™‚

    Comment by pano — May 24, 2010 @ 02:01

    • Oops. My bad. Modified the post. πŸ™‚

      Comment by Markus — May 24, 2010 @ 08:01

  4. Well you have really got me now! Lets not hype extensions too much, until I have a decent first implementation :D, which could take quite some time.

    Comment by Nikhil — May 24, 2010 @ 04:18

  5. Chrome extensions suck – buttons, buttons, buttons. And each on main toolbar…

    Comment by Livio — May 24, 2010 @ 04:52

    • Nobody said that Rekonq needs to follow Chrome’s GUI design. It simply makes sense to support that API first, because it’s already out there and real extensions are written using that API.
      After Firefox 4.0 is released, Rekonq could pick up its JetPack API as well.

      Comment by Markus — May 24, 2010 @ 08:12

  6. I think it’s time again, to think about making rekonq the default KDE browser.
    This browser is doing really well!

    Comment by Birdy — May 24, 2010 @ 05:24

    • Andrea (the main developer) wrote in a lengthy thread on kde-core-devel that he’s flattered that someone made that suggestion but also that he prefers to be in Extragear for now.

      That doesn’t mean that distributors can’t override KDE SC’s defaults. Most already ship Amarok instead of KDE SC’s default player Juk.

      Comment by Markus — May 24, 2010 @ 08:15

  7. That’s great, Chromium’s API and Qt libs!! @Birdy Kubuntu is planning to do exactly that!

    Comment by morris — May 24, 2010 @ 06:54

  8. Rekonq is making nice progress, but afaik it still needs to get some basic things in place, or I’ll resist making it the default browser on openSUSE.

    I’m mainly thinking about Java-support, mediaplayer plugins and html5 video support. Until these things are nicely working, Rekonq should not be pushed upon casual users who want to use one browser only.

    Comment by mschlander — May 24, 2010 @ 06:58

    • just to say that all the things you mentioned (java/mediaplayer/html5 video suport) depend just on QtWebKit, not rekonq. And to notice that the choice to let rekonq being the default browser here and there does not depend at all from us.
      We are just having fun, making a nice browser πŸ˜‰

      Comment by Andrea Diamantini — May 24, 2010 @ 07:30

    • First of all, the one who’s responsible to package Qt in openSUSE disabled HTML5 video support. It’s there in upstream QtWebKit. Fixing is you guys’ responsibility.

      And no casual user needs Java. The 1990s are over. Java applets are dead (except maybe in some corporate intranets). Every sane distributor would not ship Java enabled in browsers by default anyway. It’s more of a security hazard than of actual use.

      Comment by Markus — May 24, 2010 @ 08:24

      • No, not really. My bank for example requires Java to be enabled for e-banking.

        Comment by jirik — May 24, 2010 @ 09:09

      • And other banks achieve the same with HTML forms + SSL/TLS encryption πŸ˜‰

        There’s actually Java plugin support in development:

        It’s too late for either openSUSE 11.3 and Qt 4.7, but the Factory repos for openSUSE 12.0 could ship with Qt+that patch.

        Comment by Markus — May 24, 2010 @ 10:19

      • Since posting I realized that Rekonq works nicely with KMPlayer – even works for Danish National TV and Radio.

        At least in DK java applets are used by every darn home banking service, and also for login on quite a few government websites.

        If the html5 video issue is really solved by Qt 4.7 then things are really starting to look good πŸ™‚

        Just to clarify, I’m behind rekonq 100%, it’s one of the top priority apps for me when translating.

        Comment by mschlander — May 24, 2010 @ 12:12

  9. I love rekonq and it’s nice to read news like this, but why does nobody seem to worry about its memory usage?

    Comment by torgo — May 24, 2010 @ 07:00

    • Rekonq is “just” a fancy front-end to QtWebKit. QtWebKit is loaded into memory anyway because Plasma uses it.
      Considering that WebKit these days is the premier rendering engine on smartphones with restricted memory, I don’t think that its memory usage is of any problem. I don’t notice anything negative in this regard on my notebook.

      Comment by Markus — May 24, 2010 @ 08:30

    • Can you please further explain your point? That way the rekonq devs might be able to track down the issue and fix it.
      Thanks πŸ™‚

      Comment by pano — May 24, 2010 @ 09:48

      • I mean just opening rekonq with two or three tabs takes more than 200MB of RAM. I can’t go into details right now, but it’s a generic question: rekonq uses more RAM than any other web browser I’ve ever tried (and I use it almost daily and I love it, as I said earlier).

        Comment by torgo — May 24, 2010 @ 09:59

      • Seems you look at the wrong column of TOP. For me (rekonq 0.4, SC 4.4.3, Qt 4.7beta) rekonq takes a mere 20MB of RAM with 4 open tabs.
        Linux allocates way more virtual memory for every application. Here it’s 200MB as well, but that is not actually used. It’s just a reserve.
        Firefox, for example, currently has almost 800MB of virtual memory allocated.

        Comment by Markus — May 24, 2010 @ 10:12

      • I’ve just booted Arch (64 bit) and run rekonq with this single tab. RES column shows 128MB (VIRT 852 and SHR 37).

        Comment by torgo — May 24, 2010 @ 12:46

      • Maybe you use some older Qt release. I use Qt 4.7 with the corresponding QtWebKit version.

        Comment by Markus — May 24, 2010 @ 13:52

  10. This is indeed wonderful news! I am looking forward to changing completely from Chrome to reKonq (lets face it a Chrom[e/ium] with total KDE integration would be a dream come true!). Some small questions:

    * Does the QtWebkit support any of the HTML5 video codecs and will there be VP8 implementation relatively soon?

    * Is there a way to sync Chrome[e/ium] bookmarks and settings with reKonq (basically to ease transition)?

    Comment by Jens — May 24, 2010 @ 11:49

    • QtWebKit does support HTML5 video and audio features, but with Qt 4.6.x it depends on the packaging of your Qt and Phonon. As far as I heard, with Qt 4.7 the situation will change, since HTML 5 will then be displayed by QtMultimedia.

      Comment by pano — May 24, 2010 @ 12:03

    • QtWebKit does not support any codecs on its own. It delegates that to GStreamer.
      As for bookmarks:

      Comment by Markus — May 24, 2010 @ 23:14

  11. For what it’s worth, Mozilla is NOT deprecating their current XUL extension system in favor of Jetpack. They’ll be offering both options to developers, but encouraging them to take the Jetpack route as it’s a little more robust in the face of upgrades.

    Chrome’s extension system is pretty weak, in my opinion. The limitations they’ve put on ContentScripts (in the name of “security”) really annoy me.

    Comment by MrS — May 24, 2010 @ 12:06

    • “For what it’s worth, Mozilla is NOT deprecating their current XUL extension system in favor of Jetpack. They’ll be offering both options to developers, but encouraging them to take the Jetpack route”

      You just explained deprecating. The XUL API will not be removed until some later release (FF 5.0 or so), but at one time in the future it will be removed and only Jetpack will be left.

      Comment by Markus — May 24, 2010 @ 13:54

  12. Am I the only person in the world that likes Konqueror? :S

    I kinda feel sorry for KHTML, too.

    Comment by the_madman — May 24, 2010 @ 12:27

    • Konqueror isn’t going anywhere. It’s a multi-purpose tool for a different audience. There’s also a WebKit KPart for Konqueror which allows anyone to browse the web with Konqueror + QtWebKit — you can even switch on the fly between both engines.

      KHTML will also be supported at least for the entire SC 4.x life time. What’ll happen in KDE SC 5.0 in a few years or so remains to be discovered.
      KHTML has some cool features. For example it’s compatible with the HTML5 video tag since quite some time — a feature that was rarely communicated.
      However on KHTML work only a handful of people while there are lots of developers behind WebKit, including Nokia who are ensuring a good Qt port. You don’t have to be a math genius to figure out the discrepancy…
      That said, the KHTML developers are free to either fork WebKit, port features over to KHTML, or join the WebKit project to port KHTML features over to (Qt)WebKit.

      Comment by Markus — May 24, 2010 @ 14:10

      • Yeah. I have some irrational attachment to KHTML. I guess I like the idea of the work being done by 4(?) guys. Since I want to become a software programmer myself, the small number of people working on KHTML does rather appeal more to me than the countless working on Webkit.

        It’s the same way I really hate Modern Warfare 2 but love World of Goo. :/

        Comment by the_madman — May 24, 2010 @ 18:34

    • I use Konqueror all the time. Rekonq has nowhere near its features. It’s also not compliant to KDE’s HIGs (where’s the menu bar???). Not to mention the futility of porting a fork of KHTML which had as its very goal to remove KDE dependencies back to KDE. As a Fedora KDE packager, count on me to fight for Konqueror as the default until the bitter end.

      Comment by Kevin Kofler — May 27, 2010 @ 10:13

      • As a Fedora KDE packager you should know that Plasma already uses WebKit and that the KDE-WebKit bindings are also part of default SC since 4.4.
        You should also already know that Konqueror can use WebKit as well. It’s all about choice.

        Comment by Markus — May 27, 2010 @ 12:57

  13. I use rekonq on a daily base and I absolutely love it (including (k)webkit). But please give it a proper name :). Rekonq is rising and its pretty hard to change a name once it is established…

    Comment by jens — May 24, 2010 @ 19:16

    • I would say call it genocide, first you navigate then you explore then you konquer then you commit genocide. It is a play on the origional names for the other browser. I also kind of like the name it has a nice ring to it.

      Comment by joe doe — May 24, 2010 @ 21:24

      • I think your browser ate the irony tags πŸ˜‰ πŸ˜€
        Let me fix that for you
        I would say call it genocide, first you navigate then you explore then you konquer then you commit genocide. It is a play on the origional names for the other browser. I also kind of like the name it has a nice ring to it.


        Comment by pano — May 24, 2010 @ 21:27

      • wtf? My irony tags were eaten too…
        Damn it!

        Comment by pano — May 25, 2010 @ 01:34

  14. today 20 march 2011
    i use rekonq 0.6.85

    there is no translation tool, no chrome plugins tool

    perhaps with 0.6.2 ?

    Comment by promeneur — March 20, 2011 @ 15:29

RSS feed for comments on this post.

Blog at

%d bloggers like this: