Now that 4.4 is out, I finally found the time to kick off some new development and one of my pet projects these days is QGtkStyle. We already have QCleanlooks, icon themes, standard shortcuts and dialog buttons to integrate with GNOME, but to achieve true perfection we need to use the Gtk theme engine directly just like we do on Mac and Windows. QGtkStyle does exactly this, and in addition extends and surpasses QCleanlooks in a lot of other areas as well. All group boxes are now flat style to blend better with GNOME dialogs. Icon theme support has improved, scrollbar buttons are disabled at edges and item view branches now support hover.

The style is already available right now as a Qt 4.4 plugin on Labs and given that you can accept the normal disclaimers about using unreleased and experimental code, you can start playing with it immediately.

This is how the Arora browser looks:

All the above shots were taken using the “Clearlooks” engine. Here are a few alternatives:

Ubuntu Human:

Mythbuntu:

And of course the unforgettable Raleigh engine:

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:

I’ve always had a dream that Qt’s widget system would be based on a powerful 2D, or possibly even 3D, graphics engine, reaping all the benefits and optimizations that make games run fast. The reason is, coming from a 3D graphics background originally (alright, I was 16 at the time), I’ve always been puzzled by how poor application UIs perform, and how constrained they are, compared to the most basic 2D and 3D graphics engines out there. I think there are many reason for why graphics toolkits provide limited capabilities, and performance, and I’ve been studying this, hoping to help find ways for Qt to be better than the rest. If you ask me why oh why, be warned, I will talk all night.

I think I could get shot for saying this, but IMO widgets are monolithic beasts. Input, painting, clipping, geometry, events and all are almost always packed into just one class. And that class plugs into a framework that works in only one way. It’s hard to change the way a widget clips without introducing rendering artifacts (draw outside and try to update with the rendered region - oops, the dirty region is autoclipped to the widget rect). It’s impossible to know what a widget looks like without calling paintEvent(), which is a virtual function that might do something different every time it’s called. Multithreaded painting is extremely hard. It’s hard to make the widget paint outside paintEvent() in general. Couldn’t the widget just say what it looks like instead?

The main reason it’s like this, I think, is that UI toolkits’ graphics capabilities are just a hurdle in the path to the ultimate goal, which is to pull together UIs with a nice tool, perhaps targeting your favorite language, and with a cool style and the perfect widget ;-). IOW modeled vertically, after the concrete problem to be solved (which is generally speaking a good approach), and perhaps constrained by the capabilities of the primary target platform. I still think we can learn a lot from looking at UIs as a specialization of a 2D graphics scene API, rather than 2D graphics being an extension to a UI toolkit. We need to model our graphics the way that graphics works (both software and hardware), and not cling so much to a particular problem space. Make sense?

Qt provides both a high-level widget API, a low-level graphics API, and a “mid-level” canvas API called Graphics View. Graphics View is an example of loosening up the constraints of the high-level API, without exposing too many low-level problems such as geometry and dirty region handling. In a way it’s more a 2D graphics engine than anything else. It manages surfaces in 2D (or 2.5D, quasi-3D) space. Originally, we meant for it to be different from QWidget. Obviously, it’s a framework that’s meant for something completely different than widgets (vector graphics, charts, maps, IC design, large scrollable scenes, and so on). What we’ve learned, however, is that the two aren’t really that different. Why can’t I have 1000 widgets in a QScrollArea, for example.

So looking back a few years, you’ll see that we’ve made changes to improve QWidget. Without breaking compatibility of course (which is amazing in itself, shows how Qt’s architecture allows for significant internal changes).

Before Graphics View came out, in Qt 4.1, we loosened up one constraint in QWidget by enabling automatic background propagation. Now, widgets no longer had any default background (remember this change? how about QWidget::autoFillBackground oh, OK now you remember ;-)), and we were one step out of the box-model that widgets traditionally represent (btw when I use the term “box-model” I refer to a widget representing an independent rectangular region of actual screen real estate). Then, in Qt 4.2, we introduced delayed widget creation (DWC), which allows a widget to be constructed without an actual window handle. As part of the DWC work Paul, Matthias and a few others did for 4.2, they had to ensure that widgets had enough local state to independently represent what it otherwise had with a window handle, as without. Well, this had a ripple-effect. During the Qt 4.2 and 4.3 maintenance cycles, we discussed the fact that the only widget that really needs a window handle, is the top-level. With Qt 4.4, Bjørn Erik did some tough refactoring work (which some of us, me included, thought wouldn’t really be feasible), and gave birth to what we call Alien Widgets, the invisible behind-the-scenes beauty. Because of this, in Qt 4.4, a window and a widget are different, despite being the same class, in that the window signs a “contract” with the windowing system to register some screen real estate. This is the same now on all platforms.

Still, after this, you could see some strings that pull QWidget down. Painting outside paint event - using QWidget for screen shot captures, for example, required painter redirection. Each widget still constructed its own QPainter inside paintEvent(), and with it a separate paint engine, despite how all painting ended up in the same paint device: the QPixmap backingstore, which was associated with the same top-level window. Now in Qt 4.4, QWidget has a render-function, much like QGraphicsItem has a paint-function, and the window is, for a subtree of QWidgets, essentially the same as a QGraphicsView is for a scene. Puh.

Background propagation. DWC. Alien Widgets. Shared Painter. You see what’s happening? We’re on a mission. We’re closing the gap between QWidget and Graphics View. And we’re not done, there’s still more to come. There are some things that we cannot easily change, like QWidget’s clipping model for one (it’s opposite from Graphics View) [*]. And that Graphics View can’t make windows like QWidget (arguably, this is solvable though). Plus all our widgets are QWidget-based. Embedding the QWidget-based widgets into Graphics View using WoC is cool, but it’s just not good enough for full-blown exploitation…

Feature by feature, I must say the situation today looks surprisingly good. I’m looking forward to the day when I can simply assign a QGLWidget viewport as QWidget’s window. Or when I can load UIs from Qt Designer into Graphics View. Or in Qt 5, maybe the two are the same thing (the latter is usually only mentioned between some specially interested devs in Trolltech social events after consuming large amounts of beer).

That’s enough blabber for one blog post. I just felt like sharing what’s on my mind these days. This is btw all part of the research we’re doing in Development / Trolltech to support next generation UIs.

–

[*] QWidget is by default clipped to the intersect of its rect() and the localized exposed region before paintEvent() is called. QScrollArea has no explicit clipping features. Because most widgets don’t draw outside their bounds, item-imposed clipping should have been off by default (obviously expose-clipping is unavoidable for viewports that allow partial updates). And scroll areas should instead explicitly clip the widgets that intersect its edges (widgets outside shouldn’t be drawn, you don’t need clipping for that) (most 2D and 3D graphics APIs use subdivision instead, essentially real-time retesselation of the intersecting primitives to avoid clipping altogether). It’s extremely hard to change this in QWidget today without breaking compatibility. QGraphicsItem has the preferred model in place. But all our standard widgets are written using QWidget, not QGraphicsItem/QGraphicsWidget.

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

For reasons of extreme bias, I mostly like the Qt Script C++ API. However, if I had to choose one thing I really dislike, it would be the form of the QScriptValue constructors. They all take an engine pointer as their first argument. This means you have to write code like

QScriptEngine engine;
QScriptValue object = engine.newObject();
object.setProperty("redundancyLevel", QScriptValue(&engine, “Unnecessarily high”));
object.setProperty(”QT_VERSION”, QScriptValue(&engine, 0×040500));

It sure would be a lot nicer if you could do it like this instead:

object.setProperty("redundancyLevel", "Comparatively low");
object.setProperty("QT_VERSION", 0x040500);

Well, with the latest Qt 4.5 snapshots, you can! The old-style constructors have been obsoleted (but continue to work as before, of course). The documentation and examples have been updated to use the new-style constructors, and it’s looking a whole lot nicer.

That’s the moment we’ve all been waiting for… or dreading. We’ve worked for long months getting it done and you’ve all been asking for it. Some of you even realised it has already been available for a few days, unannounced… And now it’s finally, at last, there!

Qt 4.4.0 is released

Last week, we had a sneak release to current customers. And now it’s on the Trolltech homepage for the world to see. To make your life easier, here’s a download button:

We’re quite proud of this release. It’s the most feature-packed release of Qt ever and certainly the largest release since Qt 4.0.0 itself. This release adds:

• The Windows CE platform
• The Phonon new module: multimedia integration
• The QtWebKit new module: web integration
• The QtXmlPatterns new module: powerful XML support
• The QtHelp new module: flexible help support
• The QtConcurrent framework: parallel programming
• A new network resource access stack
• Support for regular widgets on Graphics View
• Support for non-native windows
• Support for shared memory
• Support for inter-process semaphores
• Support for painting on auxiliary threads
• Support for atomic operations on integers and pointers
• Improved printing support
• A new Qt Assistant
• And much more, since I will never be able to remember everything we’ve done

Not happy with all of that, we’re also bringing you:

• A video showing our demos
• A downloadable version of the pre-built demos (Windows only)
• White papers on embedded development, web support, XML, user interface styling

Continuing with the tradition started with the past minor release, we bring you those who did the work:

Oslo team	Berlin team

Trivia: there’s someone on both pictures. Can you spot who?

Some time ago we announced an alpha version of the Cocoa port. It made a minor splash and I like to say thanks to all the people that have provided feedback so far and put up with our alpha-quality release.

It was always intended that we would have snapshots available for this port, but there were so many things going on that this kind of slipped through the cracks. However, they are available now through FTP.

More info on snapshots is available here.

The open source snapshots can be downloaded here.

There are no rsync snapshots for the Cocoa port at the moment.

So, if you like life on the edge, feel free to check them out. If you’d rather wait for something a bit more “blessed,” you should get your chance soon enough.

Arora

The demo browser in Qt 4.4 has obtained a lot of attention and interest. Now that 4.4 is almost out I have forked it and started a new project called Arora where development can continue, features can be added, and anyone who wants can contribute. The source code is in a Git repository and is currently hosted on github. Along with some improvements and features there are autotest and manual tests. Git (and GitHub) makes it pretty easy for new developers to a project to fork off a branch to develop features that can be later merged back into the project. Feel free to grab the source and add the feature that you miss the most or take one of the fun items off the TODO list. To any artists out there we need an icon to match the new name. Given that this is a fork of the demo future news on Arora will be on the project’s home page or on the Arora blog.

QtWebKit & WebKit trunk

In an effort to stabilize QtWebKit before the 4.4 release QtWebKit was forked from WebKit about six months ago. This is why the acid3 test score in Qt4.4 didn’t match the latest Safari. Now that 4.4 is almost out the door work has begun on integrating the changes into WebKit trunk for 4.5. Not everything is in yet, but already a lot works and it is very exciting. I’ll let this screen shot speak for itself:

The remaining failing tests mostly relate to SVG Fonts. If you are interested in helping out feel free to join #webkit or #qtwebkit on freenode. Instructions on how to build Arora with QtWebKit trunk can be found in the Arora source wiki page.