With the announcement back in January of Qt going LGPL there was a small piece of information that slipped though the cracks of the wider news reporting, namely the fact that we were planing on opening up our repositories and development model. The first major phase of this work is now complete, and we are proud to present the results:

Launching a public repository is a big milestone for us in Qt Software, as it allows us to work closer with contributors, strengthens the the link to the community, and gives that warm and fuzzy feeling of working with open source. Granted, our releases have been open source, but our development model has not. Although you could always send us patches by mail or through our bug tracker it was a cumbersome process, requiring a faxed copy of a copyright-assignment form from the contributor, as well as a lot of manual labor on our part.

Our goal with the new site is to make this process as simple and welcoming as possible, and that’s why we will no longer ask for copyright assignment. Instead we ask contributors to grant Qt Software a non-exclusive right to re-use and incorporate the code as a part of Qt, handled by a one-time online click-through the first time you submit code for inclusion in Qt.

Maintaining your patches to Qt and working in parallel with our development is also very easy thanks to the features of Git and Gitorious. Just clone the official Qt repository, push you changes to your newly created clone, and submit a merge request for our reviewers. Everything happens on the site. (For more information on how to contribute see the Qt project wiki).

Choosing Gitorious as the basis for our public repository hosting was the result of both chance and strategy. As previously blogged about we switched to Git for our development almost a year ago, and as part of the move we installed Gitorious on one of our servers to manage our many projects and repositories. We soon started hacking on the code to add various features and tweaks, and quickly fell in love with the codebase. Fast forward a couple of months to the LGPL and public repository planning, we started playing with the idea of using Gitorious for hosting the public site too. At that point we realized that the author and maintainer of Gitorious, Johan Sørensen, was actually living in Oslo, so we invited him to our offices for a chat. One thing lead to another, and we ended up funding Johan and one of his colleagues to work on Gitorious for the past four months. The new Gitorious site is the result of that work. All of our changes have been pushed upstream, and we will continue to invest in further development of the site.

So what are the features of the new site? Johan has already enumerated these in full on his blog, but a few highlights are in order:

• Team support (easier to manage committers and project ownership)
• Asynchronous task processing (no more lag when pushing)
• Visual tweaks (including breadcrumbs and pretty URLs)

We are also looking at improving the whole review process, for example by adding line-based commenting to merge requests, bug-tracker integration, and automated testing of contributions, but these are ideas still in research. Stay tuned for updates on this.

So, what are you waiting for? Create an account on Gitorious, start cloning, and join the exciting development of Qt!

Good luck!

One of the main missing parts of QtWebKit so far has been a proper way to inspect and manipulate the document structure. In JavaScript this is provided by the Document Object Model (DOM) bindings — giving you methods like getElementById(), createElement(), and insertBefore(). These methods were also accessible in Qt 4.4 and 4.5 though QWebFrame::evaluateJavaScript(), but it was hardly a optimal way of working with the document.

The reason a proper API for this was deferred in the earlier versions of QtWebKit was because we wanted to provide an API that was not only powerful, but also easy to use. That left out using QDom, or a similar exhaustive API, as customer feedback has shown that writing code on that level can be both tedious and error prone.

Consider the following snippet:

QDomElement docElem = doc.documentElement();

QDomElement root = docElem.firstChildElement("database");
QDomElement entry = root.firstChildElement("entry");
for (; !entry.isNull(); entry = entry.nextSiblingElement("entry")) {
	QDomElement data = entry.firstChildElement("data");
	for (; !data.isNull(); data = data.nextSiblingElement("data")) {
		QDomAttr attribute = data.attributeNode("format");
		if (!attribute.isNull() && attribute.value() == "human") {
			cout < < "Data:" << data.text() << endl;
		}
	}
}

Traversing the DOM like this quickly becomes hairy. The same pattern can be found in JavaScript code: using getElementById(), traversing children, looking for a element of a certain type, etc.

Another typical use case is manipulation, where you would do something like:

QDomElement foo = doc.getElementById("foo");
QDomElement elem = doc.createElement("img");
elem.setAttribute("src", "myimage.png");
foo.parent().insertAfter(elem, foo);

Remember to keep your tongue straight when building that insertAfter() statement!

Now some of you are probably jumping on your chairs now, screaming “this is not how you would do it in JavaScript!”. And you’re right, the JavaScript world has found a way to shield off the above annoyances: wrapper libraries like jQuery and Prototype.

Taking inspiration from these libraries we did a one-day prototyping/hacking session back in November, and the results were promising. We also asked customers what they really meant when they were asking for a DOM API, and it turned out that the goal was to inspect and manipulate the DOM, but not necessarily though a one-to-one mapping of the API provided by the DOM specification. Last week we managed to reserve some cycles to continue the work, and we’re now ready for some feedback.

So how does the new shiny QtWebKit DOM API look? There’s two classes: QWebElement and QWebElementSelection.The former wraps a DOM Element, and has methods for manipulation and traversal. The latter is just a list of QWebElements, which can be iterated and extended. The frosting lies in the way elements are selected: using CSS3 selector syntax (similar to jQuery). The implementation of the selectors is already part of WebKit, so we’re basically building on a tried and tested code base.

Using the two snippets above as examples, they would become:

QWebElement document = mainFrame.documentElement();
foreach (QWebElement humanData, document.findAll("database entry data[format='human']") {

	cout < < "Data:" << humanData.attribute("format") << endl;
}

and

document.findFirst("#foo").insertAfter("<img src='myimage.png'/>");

That’s a lot easier on my eyes at least.

The initial implementation of the new API is already landed in trunk, so feel free to try it out. You can find the API documentation here, but please note that this is a work in progress, so the API may change.

Oh, and here’s a screenshot of the QtLauncher highlighting all links:

Q: Is the DOM API targeted for Qt 4.6?
A: Yes

Happy hacking!

So, after Simon snitched on me and leaked highly sensitive information about my top-secret project, I guess it’s finally time to spill the beans.

Yes, it is true. For the past few months I have been semi-secretly working on taking over the world implementing support for the HTML5 video and audio elements in the Qt port of WebKit, using Phonon as the media backend. This adds QtWebKit to the list of cool browsers that support this feature.

The introduction of a special purpose media element in the HTML5 draft allows embedding of audio and video content into web pages without resorting to using the generic object tag with some random plugin-based player. It’s as easy as this:

<video src="foobar.ogg">Fallback content here.</video>

The media element also comes with a scripting API, making it easy to roll your own player interface if you want to (or use the default one provided by the user agent by adding the controls attribute).

Employing Phonon to implement the playback started out as my “hey-welcome-to-Trolltech-here-is-a-fun-task-for-you”-project, but turned out to also be a good test-case for the implementation of the various Phonon backends we are doing here at Trolltech. The project was momentarily put on ice while we were busy stabilizing the 4.4 release, but now that 4.4 is out the door it’s time to get back in the saddle.

Some of the tasks currently in the pipeline are Win and Mac support (which is still largely untested), full screen support using overlays (for speed), routing the data through an IODevice rather than just passing a URL (which will help buffering and let us ensure that per-site credentials will work), plus implementing more of the default UI controls.

Initial support is already in WebKit trunk for those of you who want to try it out, and the finished result will be in Qt 4.5. Here’s a screenshot, for you pixel peepers out there: