I was thinking about calling this as “summer experiments”. But given a lot of them are just mind elucubrations, I’d not link them to the holiday season. Before of starting, a little warning: remember the post title!!!


It seems clear to me that a lot of rekonq “fortune” comes from (qt)webkit shining. So, given that qtwebkit developers attention is now (quite) enterely focused on Qt5 and QtWebKit2, I decided to personally fork and maintain an unofficial copy of the beloved qt4/webkit1 branch. You can find it here.

Why that?

The first motivation was because of these bugs. The others are my motivation in the “fight” with such a big project (source code is actually 4,9 Gb in my laptop. You need around 2 hours to cleanely build in debug mode and you generate around 16 Gb of “things”. You need to test gold linker to survive and you have a complete set of layout/manual/performance tests: their dirs cost around 1,6 Gb. They have automated script for build, run tests, check style, deps, create commit message, update Changelog, make coffee, etc. Please, let’s not start talking about debugging…) and the need to have an updated webkit release for the “dying” kde/qt 4 branches.
So, I definitely branched off webkit trunk on 15 of July, set qtwebkit version number to 2.3.0 and launched tests. Here are results:

Found 30300 tests.
Expect: 20467 passes (20467 now, 0 wontfix)
Expect: 37 failures ( 37 now, 0 wontfix)
Expect: 4 flaky ( 4 now, 0 wontfix)
Expect: 9792 skipped ( 9792 now, 0 wontfix)

Tests that crashed (1)
Tests where results did not match expected results (358)
Tests that had no expected results (probably new) (28)
Flaky tests (failed the first run and got a different result on retry) (5)
Tests that timed out (6)
Tests that had stderr output (145)

The other ones passed. Is it that bad to start? I hope not. I plan to fix the crashed test and hopefully the bug reported against rekonq and eventually release an unofficial, “taste the waters”, “not so stable” release. Then releasing a progressive bugfix release every month, cleaning up tests and stabilizing code. Probably not exactly as software house should do, but surely a nice example of “agile software development” 🙂

Next generation KDE browser

I’m not completely satisfied with rekonq codebase, actually. I’m really happy (and proud) a lot of people is enjoying it, but my vision for the future is not so bright. Here is because I decided to go for a couple of weekly code experiments:

It is a (k)tabwidget set as window and implementing basically all the features rekonq tabs have. I’m just indecided with the tab preview, but I saw it will be easy to add things like “pin tabs” and so on. It contains a 20 LOC class called “webwindow”, being just a lineedit + webview with 3 notable public methods used inside the tabwindow. Easy to code, to test, to expand 🙂

This is a private review of rekonq code, where the tabwidget has been removed, some things have been cleaned out and the code is clearly more compact and self contained. No strange includes in the classes. Just a triumph of the beloved qt signals/slots mechanism.
Moreover the webwindow provides some new opportunities for people (users & developers): an easy way to implement the webapps (basically cost free and full of rekonq features), the ability to better integrate with kwin, the possibility to really implement multitasking…

That’s it! I’m actually evaluating to move to a “rekonq2” repo, in the same way i.e. the amarok team did. We’ll see.


I decided that the first KDE 5 rekonq release will be… rekonq 5!!! Decided this, I have to plan what to do for rekonq 2, 3, 4. 😀
Well, I’ve got some ideas!

rekonq 1: Done.
rekonq 2: tabwindow + webwindow splitted (see previous)
rekonq 3: chromium extension support.
rekonq 4…

well, I have just these ideas in mind for now. The fact is that in the move to the kde5 (hence qt5) libs there are 3 implicit switches for us:

1) move from kde4 to kde5 (should be easy)
2) move to QML (may be it will be a pain. I hope rekonq 2 work will help a lot about.)
3) move to webkit2 (it will be another pain, given that API from webkit1 to webkit2 are so different)

Given there is so much time with this and that rekonq 2 and rekonq 3 contain so interesting things, I would not spend much more time on what will happen later, for now. Or explain why I consider such changes needed.

Here are my (summer) experiments, do you enjoy them?

8 responses to “Experiments

  1. Tabwindow, FTW!

    Keep up the great work!

  2. Great, the entire world enjoy them!

  3. “There is no saved search named ‘QtWebKitCrashes’.
    Please press Back and try again.

    Alternatively, you can forget the saved search ‘QtWebKitCrashes’.”

  4. I hope this isn’t an annoying thing to say…. Have you seen Qupzilla? I wonder whether browsing the source code can be of any use to you (GPL v3):


    It is a one-man qt-webkit browser project which has popped up recently and is amazingly featureful. It includes a plugin system and even a Greasemonkey plugin.

    I hop around quite a lot using rekonq, chrome, firefox and qupzilla.

  5. Good work, use Rekonq on a daily basis now – though I sorely miss a few extensions from FF and Chromium. Wish you would reverse the order between your 2.0 and 3.0 concepts!

  6. Yeah, I second Sinclair’s comment. Support for Chromium extensions would directly push rekonq as my default browser. Right now, there are some addons I can not live without 😉


  7. For me personally, seeing software’s version numbers rising with such a pace and without significant features backing the numbers, makes me to just not care about the software’s new releases. So are these numbers really worth it? Why it’s important to have 5.0 with KDE5? Will Rekonq’s release schedule be aligned with KDE’s?

    • well, maybe you could not read the post with enough attention. Is a complete code review allowing to manage tabs up browsing, web apps and kwin multiprocess with the same codebase enough to justify a version shift? Is chrome extension support enough? (Can you see other browsers supporting the extensions of another one?) Is moving from webkit1 to webkit2 enough? Do you understand what this means? Is moving from kde4 to kde5 enough? I think so. But I don’t understand your point. Why you don’t think it is not enough? Having rekonq5 being (probably) the first rekonq version for kde5 is just a casuality, why should we align with KDE release schedules? Do you see the differences between a “release schedule” and a “release number”?

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Connecting to %s