Interview with TrollTech’s Harri Porten

The Norway-based company Trolltech is well known for their C++ and fully OOP Toolkit, Qt. Qt is the basis of KDE, but it is also a very important and powerful tool under Windows, MacOS/X and X11 developers. Qt 3.0 released less than a month ago, bringing some really impressive features, like the ability to build platform- and database independent database applications, greatly improved internationalisation and font handling etc. Harri Porten, TrollTech employee and also a KDE developer (mostly working on the javascript part on Konqueror) answers some of our questions.1. How Trolltech chooses the parts of Qt that will be kept commercial and which parts will be open sourced?

Harri Porten: Apart from some SQL driver code depending on proprietary 3rd party libs Qt is open sourced as a whole on every open source OS. The only real difference between the Free and Commercial Editions are in fact the attached licensing conditions.

2. Please tell us about Qt/Embedded. How do you find the embedded systems market in comparison to the desktop computing one?

Harri Porten: As I see it, the embedded systems market is much more demanding in terms of product quality. Given that memory and cpu power are so precious on embedded devices, there is literally no space for sloppy code there. Consequently, buyers in this arena value Qt/Embedded’s small memory footprint and resource efficiency very much.

3. We all saw the MacOS/X port released along with Qt 3.0 and this was a pleasant release to see. Is Qt being ported to other platforms as we speak?

Harri Porten: The way Qt has been designed lends itself to easy porting. You can therefore expect to further ports to new platforms down the road.

4. Would Trolltech be interested in replacing X completely (and run X apps in a kind of compatibility mode) by using the framebuffer version of Qt? Are Trolltech’s plans to stay in the ‘GUI Toolkit’ business, or evolve Qt to a whole new desktop?

Harri Porten: Qt works on a broad range of platforms including X. That’s part of Trolltech’s business and I therefore fail to see why we should be interested in replacing any of them.

Trolltech will keep on enhancing the power of Qt as an application development framework. KDE and Qt Palmtop are existing examples of how this framework then can be used to build a complete desktop on PCs and embedded devices, respectively.

5. Are there plans to include support for vector screen elements? (eg for use in desktop icons)

Harri Porten: Vector graphics support is already present in Qt 3.0. The QPicture class is able to read and write static SVG files. Plug those pictures into QIconView and be done.

6. How .NET will affect Trolltech’s products and future strategies? Microsoft is trying to create a ‘new way’ of running applications through the internet, applications written in C# or VB?

Harri Porten: Thanks for putting ‘new way’ in quotes because there’s not much left to say. In my opinion a “port of Qt to C#” makes as much sense as a port to MFC. None. Why should we suddenly imprison ourselves into a single platform API after delivering a performant cross-platform framework for several years?

7. Is Trolltech committed to keep the GPL/QPL version of Qt for Unix Free for the foreseeable future? Are there reasons that the KDE open source developers should be alerted?

Harri Porten: There is absolutely no reason why Trolltech should abandon the Qt Free Edition. In order to guarantee the free availability even in case of e.g. a buy-out, Trolltech and the KDE Core Team have founded the ‘KDE Free Qt Foundation‘ in 1998.

8. Qt breaks binary compatibility from version to version. Will such a user-level inconvenience continue to be the case in the future and what can it be done to avoid it?

Harri Porten: Binary compatibility has only been broken two times in Qt’s history. Namely when switching to major version 2 and 3, respectively. In between those shifts – the last one happened more than two years ago – we have invested major efforts to keep compatibility between minor releases. This mostly involves a robust class design and educating every developer about the technical rules to obey

9. I noticed that Qt offers Double Buffering** features when used with OpenGL. But how about the QWidgets and the 2D Qt GUIs? There seems to be a sample code at KDE’s developer’s tutorials to achieve some basic double buffering, but it does not work for things like when resizing a window (flickers too much). Why such a feature is not part of Qt?

Harri Porten: All performance critical widgets inside of Qt make use of double buffering already. Next to the OpenGL widget that would be the 2D canvas, the rich-text editor and the progress bar for example. Somebody authoring a new type of widget is recommended to avoid excessive flicker, too, of course. Our documentation explains the necessary steps for optimizing paint events (concepts of regions and gravity) in a far less resource hungry manner. As the KDE example shows the brute force solution of double buffering is easily available as well.

10. In the past, Qt was not thread safe. I hear that this is not the case anymore. Do you have plans of making Qt more multithreaded (which could help a lot in jazzing up the overall UI responsiveness) by implementing something like a Qt Thread instead of having to use OS-specific threads each time?

Harri Porten: Thread support was introduced in version 2.2. Platform specific details are covered by the QThread, QMutex and QWaitCondition classes. They allow controlling threads, locking and thread-safe posting of events. This doesn’t mean that every single Qt class has become thread safe but support for separating a GUI thread from non-GUI threads is there. Making e.g. container classes thread safe is planned in the long run but meanwhile, high UI responsiveness can also be achieved by simple use of timers.

** [Double buffering is a technique where graphics is rendered to an off-screen buffer and not directly to the screen. When the drawing has been completed, the program calls a swapBuffers function to exchange the screen contents with the buffer. The result is flicker-free drawing and often better performance. Update: Daniel Switkin emailed us for a correction: “Actually, this is page flipping. Double buffering draws offscreen, then blits that to the frame buffer (there is no exchange or swap done).” Thanks Daniel.]