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

Henrik recorded some cool videos showing off a bit of the integration of WebKit into Qt. The Quicktime videos are at the bottom of our QtWebKit announcement page, showing WebKit in designer, integrating Google maps into your Qt application or how to embed native widgets into HTML.

Congratulations to the entire KDE team for this release!

It is for sure the best release ever - due to the technology and also the excellent team effort. It takes a lot of guts to make a point-oh release and I’m very impressed by their courage and strength.

P.S.: I’m happy to be able to post this from within KDE 4 itself

The temperatures in Oslo have been dropping rapidly in the last few days, we’re well below zero now. The same applies to Qt where Thiago opened the fridge of feature freeze. I like how things fall into place :). Actually I have the same feeling with QtWebKit right now. The pieces of the puzzle are falling together, with lots of really good progress:

• We have integrated a copy of WebKit into the Qt sources and we’re updating it frequently.
• Shortly after the integration Friedemann, one of the fearless Designer hackers, added a plugin to embed WebKit into Designer, along with support for QUrl properties. See the screenshot below :).
• Lars and Holger finished the separation of QWebView and QWebPage. The latter is now a standalone QObject that allows embedding WebKit into non-QWidget environments.
• Michael Goddard of the TT Brisbane hackers started working on improving the QObject bindings inside JavaScriptCore, to make them behave like QtScript’s bindings with regards to signals & slots, properties and child objects. You can follow the progress in the branches of our public git repository.
• Holger fixed lots of bugs in the event handling. The Web Inspector works much much better now.
• We have written a little demo browser application to show the use of QtWebKit. It’s in demos/browser in Qt and this blog post was written using it :)!

So Holger (zecke), Girish (g-man) and me (tronical) made it to Foss.in in Bangalore in India. We’re having a great time here, a great atmosphere, awesome food and a nice and warm climate. Girish had a presentation about Qt Stylesheets, I gave a presentation about (Qt)WebKit today and Holger had a presentation about OpenEmbedded. And there is probably going to be another lightning talk tomorrow about WebKit :). As a little side-note we found a rather interestingly named candy-bar. Have a look at it yourself:

It’s been a while since the last update and a few things happened that are worth reporting.

• George and Adam visited us in Oslo for a week. We’ve spent a fair amount of time discussing all sorts of topics and we have moved our Git repository over to http://code.staikos.net. The new machine setup makes it possible to give contributors push access.
• Adam did a lot of great cleanup work in the QtWebKit Wiki pages, including instructions on the use of Git with WebKit’s Subversion repository for example
• We have started reworking the API on the class level. You can follow the work in the shared/api-changes branch. Right now we want to have a toplevel QWebView class that is a QWidget and provides all the convenience to cover most use-cases. Below that we place QWebPage which contains page related functionality like the actions and the history. The page then provides access to the QWebFrame objects, which deal with the per-frame scrollbars and allow rendering into a given QPainter.
• Thiago integrated the new network access API into Qt and work has started in the shared/network-access branch to port QtWebKit over to use that API. This will completely replace the existing public networking API in QtWebKit when compiled against Qt 4.4. Of course we will keep the old QWebNetworkInterface API around when compiling against Qt 4.3.

It’s time for another update on “what’s happening” on the (Qt)WebKit side of things

• We’ve been working on preparing the API for a first round of review. As a result of that we have finished the action API in QWebPage that I mentioned in my previous blog. QWebSettings has changed to a pointer based class: Every page returns a pointer to a QWebSettings object and there is static QWebSettings *QWebSettings::defaultSettings(). The individual attributes in the settings are inherited to QWebPage. This makes it easy to apply one global setting to all instances of QWebPage for example:

  QWebSettings *settings = QWebSettings::defaultSettings();
  settings->setAttribute(QWebSettings::JavascriptEnabled, false);
  

• Lars has implemented a cool new class called QTextBoundaryFinder to find the boundaries for graphemes, words, lines (line breaks) and sentences in a QString. The text iterators in QtWebKit use this class now and provide correct navigation when live-editing is enabled on an HTML element.
• We’re also working on integrating QtWebKit into Qt itself. Our goal is to include a snapshot of all the sources including the ones generated by build scripts into the Qt source tree. This will make it easier to build QtWebKit itself when it is shipped with Qt.
• On top of that we are going to have a little QtWebKit hacking workshop next week here in our TT headquarters in Oslo. We plan to lock ourselves in an office and clean up some internals with the help of George and Adam.
• BTW, Maciej has posted a nice summary about the features in WebKit 3 in the Surfin’ Safari WebKit Blog. QtWebKit is based on the same version and has all the features he describes.

Politics aside I’d like to summarize a bit what happened during the development of the Qt port of WebKit in the last weeks. I like technical details, so I’ll concentrate on those

• Lars has worked like crazy to implement support for editing in the layout tests. That means we pass now a whole lot of tests that verify that the on-the-fly editing of web pages works. You can use the contenteditable attribute on HTML elements and they are fully editable in QtWebKit now.
• Holger has reworked the network job handling introducing priorities. Based on that he fixed support for synchronous downloads and ensured that during a synchronous download no async jobs are served. This is used for example for synchronous XMLHttpRequests.
• We have started going through the public API again and making comments to things we want to change and fix, in the api-changes branch in our public Git repository
• I’m reworking the context menu implementation and combining it with a nice API to retrieve QAction objects from a QWebPage. The state of these actions is maintained and you can plug them into toolbars, menus, etc. That will make it easier for developers to customize features like the context menu. Also it simplifies the KDE integration to apply KDE settings such as icons because it’s just one webPage->webAction(QWebPage::Reload)->setIcon(…); call and the action will have the right icon in the toolbar or the context menu.
• We’ve finally set up a buildbot for the Qt/Windows build of WebKit. This will make sure that compilation always works.

As we plan to integrate WebKit into Qt 4.4 we have to choose a stable code base of WebKit. As Maciej announced on the webkit development list the trunk branch of WebKit is going to be merged with the feature branch and likely to more feature development in the future. Apple instead is going to create a safari-3 branch in WebKit’s Subversion repository and use that for stabilization. We decided to base our work on that stable safari-3 branch. At the same time we decided to switch the development of our patches of the QtWebKit port from Subversion over to git. Our development branches will be hosted on a public git repository here in the Trolltech Labs. You can browse it online through the GitWeb interface. The repository itself is also available through the git protocol, so you can clone the repository and follow our development. Every change that we put into the qtwebkit branch - which is based on the safari-3 branch from Subversion - we also plan to submit into WebKit’s trunk branch in Subversion.

This development model allows us to stay open in our development and makes it easy to publish experimental work. At the same time it should be easy to merge changes between branches and stay in touch with the official WebKit Subversion repository. The svn/* branches in the Git repository are automatically imported from Subversion.