KDE’s WebKit browser Rekonq gets extension support

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. πŸ˜€

Advertisements

40 thoughts on “KDE’s WebKit browser Rekonq gets extension support”

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

    1. 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.

  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.

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

  3. 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.

    1. 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.

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

    1. 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.

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

  6. 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.

    1. 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 πŸ˜‰

    2. First of all, the one who’s responsible to package Qt in openSUSE disabled HTML5 video support. It’s there in upstream QtWebKit. Fixing https://bugzilla.novell.com/show_bug.cgi?id=596573 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.

      1. 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.

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

    1. 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.

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

      1. 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).

      2. 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.

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

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

  8. 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)?

    1. 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.

  9. 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.

    1. “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.

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

    I kinda feel sorry for KHTML, too.

    1. 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.

      1. 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. :/

    2. 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.

      1. 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.

  11. 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…

    1. 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.

      1. 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.

        πŸ˜€

  12. today 20 march 2011
    i use rekonq 0.6.85

    there is no translation tool, no chrome plugins tool

    perhaps with 0.6.2 ?

Comments are closed.