Tag Archives: webkit

Rekonq 2.2

It’s that time again, release time! In this period it seems very easy to round some edges and push up things.
And this because of the great contribution people is giving us via patches, comments (also on this blog), bug reports… I cannot remember a release where I coded myself so little and checked patches and suggestions so much 🙂
The result is this rekonq 2.2 release!

Continue reading

rekonq 2.0 first stable

It’s that time again, the time for a stable release! And I’m really excited this time as this 2.0 marks the beginning of a real new era for my pet project… But let’s try do things slowly and in the right order!
Continue reading

rekonq 2 alpha

Hi Guys,
just a short notice this evening from my bed where I am sick (quiet, nothing serious): rekonq 2 alpha has been released to the wild!
You’ll find there all the code to implement the features announced in the tech preview one month ago.
So, nothing really exciting, but a nice step towards our “next generation” browser. In fact, in addition to the new features, rekonq 2 has been an attempt to re{view,organize} all rekonq codebase.
Time will say if the experiment succeded. A first nice proof of this is the native support for web applications.
So, run downloading code here or ask your preferred distro to package it. And enjoy 🙂

rekonq: October news!

Let’s start with this…

Continue reading

rekonq 1.2

I’m happy to announce the immediate availability of rekonq 1.2. You may know, rekonq is a web browser based on webkit & kde technologies that aims to be fast & lightweight.

This stable release contains just some bugfixes over the 1.1 one and should be the last for the 1.x series. In fact, the core development is moving to the upcoming 2.x series, where some big news have been announced: you may notice the most notable one in the screenshot here 🙂

rekonq 2 preview

News about the 2.x series and a first technologic preview is expected for the end of this month, while a first stable release is planned for Christmas.

Enjoy rekonq 🙂

rekonq 1.1

Just a short post today to announce the immediate availability of rekonq 1.1. There are 10 or more bugs fixed since 1.0. In particular, this should fix all troubles with the upgrade to KDE 4.9 related to the search engines. Unfortunately I could not yet fix the problem reported about download dir “management”. But if you don’t know what I’m referring about… well…no worries and go straight on!
You may have noticed I updated also rekonq website. I did it while following last sunday’s football matches. That’s because the guy offering to create on our new website is having problems at work and had to postphone his work on it. Anyway, shouldn’t be that bad for one month or two 🙂
Next update will arrive with infos about 2.0. In two weeks from now.
Stay tuned. Enjoy rekonq 😉


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?