We had a few days with an intense bug fixing session here in Oslo trying to get the Qt 4.2 Tech preview out of the door. It’s now available since about an hour.

Lots of work has gone into adding new features. Just check out the 4.2 intro page. But apart from the larger features mentioned there, lots of work has also gone into less visible areas:

• Up until 4.1 Qt was now creating native window handles when the QWidget was constructed. This has now been changed to creating the handles on demand, something that decrease application startup time and resource consumption.
• Qt now contains a parser that can parse CSS syntax. Currently the parser gets used in two places: In the HTML import for QTextDocument/QTextEdit to parse <style> tags and external stylesheets correctly. The other usage is in the new setStyleSheet() method of QWidget. This is still a bit undocumented, but it allows you to style your widgets using a CSS like syntax. Try for example calling setStyleSheet on QApplication with the following sheet:
  QPushButton { color: white; background-color: red;
border-width: 2px; border-style: outset; border-color: yellow;
}
QPushButton:pressed { border-style: inset; }
QMenu { background-color: #00cccc; selection-background: brown; }
• Another feature that is not mentioned, is that we now have a QWidgetAction class that can be used to add QWidgets to menus. In contrary to the similar feature we had in Qt 3, this one does now also work on Mac OS X.
• Another thing you can do with Qt 4.2 is to add application private fonts to a Qt application, by just specifying the path to a truetype font (or embedding it as a resource into your application).

There are lots of other things that are not mentioned in the 4.2 intro page that I won’t mention here neither, but I’m sure you’ll find them.

As always we will be happy to get your feedback on the new features.

Have fun playing with the Tech Preview

Starting up a new office is a funny ordeal, especially in a country where you don’t know the language and maybe even WORSE, you don’t even know the trash sorting routines for recycling!

Anyways, one thing I should have an ok knowledge about is setting up my new machine. Having used Debian for a long time I thought it was time to move on to something more fashionable like Kubuntu (Dapper). The basic install went like a breeze, then ofcourse starts some fiddling with getting accelerated graphics drivers and getting X to behave as wanted, but it all went fine. Sound even worked out of the box without a problem too! Kinda…

The first problem was trying to define the default sound device. For me I got sound through my USB headset, while Matthias got sound through his AC97 compatible motherboard soundcard. We tried asoundconf set-default-card and all that crap, but never got it working properly. Solution? We just disabled the motherboard sound chip with a jumper

The second problem was getting several applications to access the sound device at the same time. In my ignorance, I believed this problem had been solved at this point and it was just my old crappy Debian system that couldn’t play XMMS and Flash at the same time. It might not sound like a serious issue, I mean how often do you really need two apps playing sounds at the same time? All the freakin time! is the answer to that question.

We’re going to use some form of voip to communicate between the dev team offices, so we will have either Skype or OpenWengo or whatever works in a comfortable way cross platform, so there will always be an app like this running. And we all like music, so we’ll have some app for that too running. Then there is Flash and all the other small apps that sometimes needs to play a happy tune.

So, I installed the latest Skype 1.3 Beta that uses Alsa, and fired it up. The test call didn’t work cause it had “Problems with sound device”. I killed amaroK (running the Xine engine), and then Skype worked. I then spent the next seven hours playning around with arts, alsa, dmix, reading about jack and esd, trying restarting, rebooting, piping, mixing, enabling, disabling, swapping, switching and then in the end - just crying. The only time I had actually gotten two sounds playing at once was when pressing “Test Sound” in the Sound and Multimedia - System Settings dialog. It was just like trying to set up the Sound Blaster emulation in DOS for a Gravis Ultrasound all over again - only this time it was less fun.

On Windows there is DirectSound or ASIO. One can select the default device for the OS, and one can override this if one feels like it in the running applications. Simply explained, DirectSound is for games and normal applications, while ASIO is for professional audio usage - and most important of all - they work. (There is also MMSystem, but it’s old and dead).

I think it’s strange this is still an issue on Linux.

No, this is not a GNOME application, but a Qt 4 app running on GNOME.

Plastique was designed to closely resemble the default style in KDE. With Qt 4.2, we are introducing a new style that will blend better into standard GNOME based desktops as well.

The style is based on the current default style for GNOME, Clearlooks. It will also be available on other platforms.

The new Plastique style (see earlier posts about Plastique2) is making its way into Qt 4.2. It’s not 100% done, but it’s much better than what it used to be. Hopefully it’ll be complete within few weeks after the snapshots are out. Beware of off-by-one rendering errors, though. Once y’all dig your hands into the upcoming Qt 4.2 snapshots, let us know what you think (and even better, help us spot more of those style bugs/annoyances!).

As some of you might have noticed we’re expanding into Germany, more specifically Berlin, even more specifically Adlershof, even EVEN more specifically Albert-Einstein strasse 16. The honorable task of getting the keys and opening the office for the very first time fell on Thomas and me, I wonder why Matthias didn’t do it himself - might have to do with the time of the handover - 07:55 Anyways, the office is pretty cool and much lighter than I thought from the initial pictures. As I’m typing now I’ve got a nice view from the seventh floor and can see the cracy TV tower at Alexander platz in the distance.

At the moment we have network - YAY!, but no machines - BUH! We went shopping for lots of stuff today though, so within this week we should have most of the essential stuff.

I’m also proud to say that the Berlin office already has found their first bug, and can even top Matthias promise that the office would be operational within a week.
We didn’t fix it though, as it didn’t fit with our current submit policy

Rumor has it it rained today in Oslo and I’m very sorry to hear that, and to cheer you up I send you this picture of us having lunch on the roof terrasse of one of our local cantinas. Hope it helps.

I’ll leave you with a picture of a happy liege lord in his new fiefdom.

[Disclaimer: Qt 4.2 is not released yet, and anything can still change.]

QTextStream in Qt 3 was unbuffered. Feeding bytes by bytes into a codec which appended QChar by QChar into a QString, it did have room for some speed improvements. So in Qt 4.0, we introduced QTextStream’s replacement: … QTextStream! That is - we completely refactored its insides, but kept the API more or less the same. The new QTextStream is buffered. That gave QTextStream in Qt 4 a 16x performance boost over Qt 3. For most operations, it’s just about 1.5x slower than raw QFile access. Which is very very good.

The downside from this change was that the stream’s device position, which can be retrieved by accessing QTextStream::device()->pos(), became unreliable. Because QTextStream buffers its input, it reads ahead a chunk of bytes. In Qt 3, QTextStream was always in sync with the device position. In Qt 4, the device is way ahead! And this upset some people who ported from Qt 3 to Qt 4, who used seek() and pos() together to navigate text files.

Thiago Macieira and I found a beautiful solution to this problem, and I just submitted QTextStream::pos() into what will become Qt 4.2. Together with QTextStream::seek(), which does what QTextStream::device()->seek() did in Qt 3, you can do exactly what you could in Qt 3, but it’s just faster than before.

In addition, Qt 3’s textstream class has been ported into Qt3Support, so you’ll see a Q3TextStream class which will make porting even easier.

After porting kdelibs to D-BUS and Thiago’s blog entry about controlling a KDE application via D-BUS, I decided to give it a try. After a bit of playing, I came up with a solution that automatically exports a com.trolltech.AccessibleObject interface for every widget (see screenshot).

The command dbus :1.63 /Window1/CurrentValue com.trolltech.AccessibleObject.description (where :1.63 is the app’s bus ID) returns the accessible description of that widget:

sending message: QDBusMessage(type=MethodCall, service=”:1.63″, path=”/Window1/CurrentValue”, interface=”com.trolltech.AccessibleObject”, name=”description”, signature=”", contents=( ) )
got message: QDBusMessage(type=MethodReturn, service=”:1.63″, path=”", interface=”", name=”", signature=”", contents=(QString(”The current value”) ) )

All my code does is to wait for a widget’s create event and attaches a QDBusAdaptor to the newly created widget. The neat thing is that D-BUS takes ownership of that adaptor, so whenever the widgets gets deleted, the D-BUS interface vanishes as well. The total code to export the accessible information is less than 100 lines of code. And the best thing: The code is readable. The accessible information can be accessed from any language without hassle, even from command line (I can imagine some pretty handy scripts emerging).

Both QA and accessibility tools have a common problem: They need full introspection of the user interface and need to simulate user input. The big difference is that QA tools need to simulate a real user, whereas accessibility tools need to give a user a different path to use a GUI. Mixing the two concepts just because it is convenient is not doing disabled people a favor. Developers might be forced to change the accessible representation of a widget to enable some QA tool to work, thus confusing disabled people with a bunch of unneeded functionality. Most GUI toolkits have hooks to introspect widgets, which is what should be used for QA.