rekonq 2.4.0

Here we are again, after a tiny pause, ready for a new release! Rekonq 2.4.0 has been released to the wild! What’s new in this release?
Here is a short summary of the most interesting things:

  • added a simple ssh sync handler, so that you can sync history, bookmarks and password over ssh
  • adblock improvements: faster startup setting load and domain-specific hiding support!
  • a general work on startup settings: changed some defaults about HTML5 and WebGL, automatically loaded if available. Also, some small improvements on startup speed
  • bugfixing

This is the first rekonq release after Bluesystems stopped funding me for rekonq development. I have to thank them a lot for this year together playing to realize the best open source software in the World! I heard they are concentrating their strengths now in the plasma workspace: hope them best luck :)
Anyway, what about rekonq future? I’m currently involved in a new project in my job and I’m planning to restart the usual development in rekonq from christmas on. I’m actually evaluating just a new tiny feature about a random password generator. You’ll see if it will fit in ;)
My main concern is actually about the direction the development should go: the most important decision is about the underlying web library to adopt. We are actually based on QtWebkit for Qt 4.x. But this is quite old and basically “unmaintained”. And this for our users mean just one thing: crash bugs!
The same library in Qt 5, the so called qtwebkitwidget library has some improvements about javascript and performance in general, it’s not so old, but as far as I understood, it is the “less possible” maintained. It will be surely easy move from the actual one we use to this, but I don’t think it can be more than a “point of passage” from Qt4 to Qt5.
Next option is the QML/Qt5 web library based on the so called “webkit2″. Well… this is born right now and it will basically die in Qt 5.2. So, you cannot even consider it.
Last option is the Qt WebEngine. It will be based on Chromium/Blink. References about what will happen in Qt are here. If you have read it, you probably noticed that there will be no usable Qt WebEngine release (for a browser) until Qt 5.4. So, something around 20 months from now.

All this to state: I no more want to release Qt4 based versions, but I cannot (yet) release serious Qt5 ones. I had to use this time to work on code refactoring, GUI/feature separation and so on. I’ll try to insert your preferred (tiny) feature here and there, in the while.
Hope you’ll like it ;)

Enjoy rekonq!

34 responses to “rekonq 2.4.0

  1. Not to take away anything from your argument, but how does “20 months” as the release schedule follow from: “The first fully supported release will then, most likely, come as part of Qt 5.3 next spring. “

    • Hi Hannu,
      as far as I understood qt plans, Qt 5.3 will see the first release of this new WebEngine, but it will not have enough API to implement a browser over it. Next releases will include more. So next spring (or summer) + 9/10 months for Qt 5.4 release + 3/4 months to work about it = around 20 months.
      If in Qt 5.3 we will have all the things we need exposed in the WebEngine, you have to reduce 10 months from my numbers.

      • Qt 5.4 is scheduled for October 2014. Qt 5.3 will have a quicker release than normal so they can stop having December releases like they are having this year and last year. Granted they might not hit that month exactly, a few weeks late is the norm… but you are being wildly pessimistic! Qt 5.1 was mostly delayed due to infrastructure issues which shouldn’t be repeated, I think they’ll be able to hit their 2014 release schedule without much trouble.

        The QtWebKit in 5.2 has some nice improvements it sounds like, being basically the iOS 7 branch of WebKit.

        But isn’t the main thing holding an app like Rekonq back the state of the KDE libraries you depend on in KF5? If Rekonq was a Qt-only app I’d say there would be no reason to not port yesterday, it’s so easy to port to Qt 5 (all I had to do was a global s/QWeakPointer/QPointer/ and adjust my cmake files essentially.)

        Anyways defer the QtWebKit vs QtWebEngine question to when the KDE deps are ready, but likely stick with QtWebKit to start out with.

        • Hi Ian,
          I would not be pessimistic, sorry for that. I’d just to underline that the main library rekonq depends on is QtWebKit and that actually that web library is in a “moment of passage”. I have not mentioned the kde4 –> kf5 move for rekonq just because I think there are 2 decisions to make before: what web library rely on in the future and what UI technology adopt (QML vs QWidget).

          • Well you might consider deferring that decision until after KF5. A release that is built with QWidget, QtWebKit & Qt5 wouldn’t be much work once KF5 is in place. Most of the work would probably be adjusting to changes in KDE that will be relevant regardless of big questions like QtQuick 2 or QtWidget and when to switch to QtWebEngine.

  2. Pingback: PING: Tizen, Scientific Linux, Steam Controller, Xubuntu, Hawaii...

  3. A big problem I have with Rekonq (2.3.2) is when I have a lot of tabs opened, Reqonk loads all tabs, and its contents, when starts at the same time. Would be better load all tabs but only contents from the actual tab like other browsers do.

  4. I’d rather recommend you to stay away from a classical webkit because I disagree with at least some developers about the proper balance between “desktop integration” and security-related sandboxing.

    Right now, all webkit-based browsers (including Rekonq) that use the GStreamer stack for html5 audio and video handling have what I think is a vulnerability. See and for details – but what’s much worse is that WebKit developers think that it is the right thing, not a vulnerability. Chromium does not have this bug.

    Also note that there are other bad consequences of 1:1 mapping of audio/video elements and PulseAudio streams, as done by WebKit. Namely, a web page that plays 32 streams of pure silence is a complete DoS of the sound system (i.e. no program will be able to play any audio), because PulseAudio has a hard-coded limit of 32 simultaneous streams. And they also do passthrough, which amounts to the same DoS if a web page plays just one stream of pure silence in a passthrough-capable format!

  5. Whats about the Chrome Extension Support please?
    Thanks a lot for your great and clean Work! :D

    • Hi,
      the fact about Chrome extensions support is that I really cannot work on it without funding. So my work on it is actually suspended/aborted. If some devs are interested working on it, I can provide my tests/development branch to start from something done, that is (no more than) 25-30% of the job.

  6. Thank you for this release !

  7. Pingback: PING: Tizen, Scientific Linux, Steam Controller, Xubuntu, Hawaii… | Support-Tech

  8. QtWebKit is still maintained. In Qt 5.2 there will be a new version based on a the latest/last snapshot from WebKit trunk.

    • Hi Allan,
      I know that there is a lot of work actually around QtWebKit for Qt 5.2. But what it is unclear is about the future. I’m starting actually now to approach the Qt5 world and I’m a bit confused about webkit. You just have 2 libraries about and I read about plans for a third one. In my opinion this means that this third library is going to replace in the near future the other two. Or are you stating the Qt Project will maintain 3 “different” web libraries? :-o
      Another thing I couldn’t properly understand is “what” QtWebKit has improvements in Qt 5.2: the “old” one, based on QWidget or the one exposing just the QML webview type? Both?

      • There’s just QtWebKit and QtWebEngine. There’s a few ways to use QtWebKit (QWidget, on a QGraphicsScene, QtQuick 1′s WebView, QtQuick 2′s WebView), but it’s all QtWebKit. :)

        QtWebKit’s future is deprecation, but it is a fine choice of library to use in 2014. Allan Jensen is the maintainer of QtWebKit and will keep the boiler hot it sounds like.

        At work I use QWidget’s QtWebKit, I feel OK. :)

  9. Pingback: Релиз web-браузера Rekonq 2.4, развиваемого проектом KDE | — Всероссийский портал о UNIX-системах

  10. Then there is the question of QML based rekonq later?

    Thank for your work. I can hear you. It is a bit of unstable (hopefully) interim period for the Qt web world.

    • Yes!
      I’m quite sure they took the right decision with chromium/blink and the WebEngine. It’s just a question of time, having a stunning web library in a Qt fashion, competitive against other major browsers.

  11. What a mysterious company is BlueSystems… Is it all just about funding KDE developers?

    • Hi Diego,
      I don’t think so. They just started supporting KDE choosing the most stunning free developers :D
      Now they are renovating their efforts, concentrating over plasma and the KDE workspace.

  12. Pingback: Rekonq 2.4.0 añade sincronización mediante SSH y mejoras en Adblock

  13. I an a user of Rekonq. Here is what I think:
    I suspect this is posable but not with out some work…
    I like FireFox for its stability which is mainly attributed to its layout engine, gecko. Perhaps it would be worth wild to have rekonq adopt gecko. This may bring greater stability to rekonq. I know that with kmozilla you can use gecko in Konqurer. Also gecko is well maintaned by mozila, so int’s just you having to implament it. It may not be sexy qt, but qt doesn’t seem to have the answer to the Qustion: I need a stable layout engine, which to use?

    • Hi Seamus.
      Moving to Gecko is not in the plans. As said before, I’m really curious about this new Qt Web Engine announced for Qt 5.3/5.4.
      We’ll see what will happen ;)

  14. Pingback: Rekonq 2.4.0 ya permite la sincronización (SSH). Instalación en Opensuse 13.1 | Noctuido

  15. Something I noticed in this version – fonts now don’t use system sizes. To explain what I mean: I have a 141 dpi screen in my laptop, with dpi settings set accordingly 6-point font looks roughly the same size as it would look on paper; before 2.4.0 6-point font in rekonq would look the same as elsewhere in the system, but now it seems I have to convert points into pixels and set font size in pixels, which seems a bit silly to me. Is that a bug or is it intentional? If it is intentional, could you please clarify reasoning behind this change? Also, do you accept donations? I can’t promise to fund development single-handedly, but I would definitely try to help as much as I can.

    • Hi Moonwalker,
      I admit I’m not an expert in this dpi screen problem. I’ll try to investigate and eventually release a fixed version ASAP.
      About donations, I think the easiest way is the kde-apps donations system.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s