As part of Qt 4.4 we have now made our very first release! 
Shortly before the release we finished merging all our changes back to the Subversion trunk branch, where we are working directly now. We will continue to maintain and bugfix the code in the Qt 4.4.x release series, but we try to make the changes in trunk first and then backport changes as they fit.
Our current goal is to catch up with the architectural changes that happened in trunk and maintain the layout tests. Holger for example fixed the HTML Canvas after some internal API changes. Ariya started working on Netscape plugins for Windows and Tor Arne I heard is polishing a secret feature he’s been semi-secretly working on for a while now in not-so-secret trunk. I heard rumors that he’s going to secretly blog about the secret feature soon, so stay tuned.
Big props also to Marc and the guys at Collabora for landing the initial support for Netscape plugins for the X11 Qt and Gtk ports in WebKit trunk! Great job!
On the application side Urs Wolfer’s Google Summer of Code project for integrating QtWebKit into KDE has been accepted. Congrats Urs! Feel free to stop by in #webkit and bug us if you have questions 
13 Responses to “QtWebKit Development Update”
You’re welcome, specially considering you and the other people at Trolltech helped us a lot! You can find more info on Marco Barisione’s blog: http://www.barisione.org/blog.html/p=128 .
Hm, I’m not sure I totally get how - or better: where - you develop QtWebKit now. Is it developed inside its own branch in the WebKit repository? Or are you developing your own “fork” with occasional synchronizations to the WebKit main branch?
The reason behind my question is that in one of the recent discussions about WebKit and QtWebKit it was mentioned that QtWebKit is in fact a port of WebKit, and therefore fixes in WebKit would take months until they would land in QtWebKit - and even more months until they would land in KDE (like in Plasma). Is that true to some point?
Or asked the other way around: if I would use Arora, how long would it take until a fix in WebKit would come down the pipe and lands in Arora?
Now that we’ve merged our changes we are submitting all our changes to Subversion trunk first. You can use Arora with QtWebKit compiled from SVN trunk as well as with what we ship with Qt 4.4.
Simon, you didn’t answer to liquidat main question. And I’m also interested in this one. Is it developed inside its own branch in the WebKit repository? Or are you developing your own “fork” with occasional synchronizations to the WebKit main branch?
And even more importantly: what should distros ship? The version of QtWebKit included with Qt or the version included in the WebKit snapshots?
There is also foxkit which is an Arora fork that is going to use webkitpart and be a full fledge kde web browser that is going to use all of the KDE coolness such as kross, kio etc
Koko, liquidat:
As I said, we submit our changes to SVN trunk first. trunk is the main line of development. There is no separate branch. We do maintain a separate branch of QtWebKit in a git repository at http://code.staikos.net/ for the Qt 4.4 based version of QtWebKit. But our main focus of development is on trunk right now.
Kevin:
As far as I know the distros ship QtWebKit as it comes with Qt 4.4. Only that version ran through our QA and is supported as part of the regular Qt support agreements.
> trunk is the main line of development
Sorry if i seem dense, but (just to be sure) which trunk are you speaking of ? The Qt trunk or the Webkit trunk ? If it’s the Qt trunk, i believe that the questions of Koko and liquidat are still unanswered - that is: how are QtWebkit and Webkit synchronised ?
liquidat, koko: QtWebKit is part of WebKit and therefore developed in the WebKit repository. It is not even a branch.
kevin: Ideally distros should ship QtWebKit that is included in Qt. This is because QtWebKit “trunk” is considered a “bleeding edge” version and may not even work.
MrFurious: “trunk” here is WebKit trunk.
There is a problem with the native-widgets-on-Webkit feature: you cannot push that content to a browser such as Firefox, Opera or even Internet Explorer, you are stuck with making your application a fat client. It would be nice if Qt was able to generate HTML + CSS + Javascript to paint those widgets, such as Wt ( http://webtoolkit.eu/ ) does. I talked about this with Holger at Guademy 2008 ( http://guademy.org ) and he seemed interested.
This conversation really made me happy. I thought QtWebKit was a fork too. It really isn’t. Look, you can see all the bleeding edge Qt code here:
http://trac.webkit.org/browser/trunk/WebKit/qt/Api
This is really quite slick. Basically in the WebKit directory they have thin wrappers for WebCore for varios platforms (mac, qt, gtk, etc). Then the bulk of what we call WebKit is really implemented in WebCore here:
http://trac.webkit.org/browser/trunk/WebCore
In other words, in theory if you replace your local copy of WebCore (in my case qt-mac-commercial-src-4.4.0/src/3rdparty/webkit/WebCore) with the stuff in the official WebKit trunk, as well as the latest WebKit/qt directory, you may be able to get it to build and link against it and theoretically pass the latest Acid test.
Very cool. The only question that remains is how are the official WebKit svn respository and Trolltech git mirror synced. Hopefully this is done automatically so that qt-snapshots could also use the mainline WebKit code. I suspect this is not yet the case, but something Trolltech should consider doing in the future.
Will: you don’t need to replace the (Qt) local copy of WebCore, just compile QtWebKit trunk and use it as the replacement. For example, Arora browser can use either QtWebKit from Qt 4.4 or QtWebKit from trunk. BTW, the WebKit git repo is of course synced automatically with the WebKit svn repo. However, so far qt-snapshot is only manually updated for practical reasons (to ensure that it builds properly, does not introduce regressions, etc etc).