Experiments

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!!!

QtWebKit

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)

RESULTS
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:

tabwindow

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 🙂

webwindow

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.

Numbers

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?