Qt 4 mostly tries to preserve source-compatibility with a little search and replace and a COMPAT compilation switch. More porting will be required for styles and code that uses the meta object system directly.

The increased startup performance will be reached through reduced number of symbols, less read/write data and fewer static initiliazers. Fewer mallocs, faster and more optimised tool classes and reduced memory consumption will improve the runtime performance enabling Qt 4 to run on embedded devices that are slower and have less memory than today's desktop computers too.

To back up these statements Matthias gave some numbers about Qt Designer which was ported to Qt 4 with only the necessary changes to make it compile: The libqt size decreased by 5%, Designer num relocs went down by 30%, mallocs use by 51%, and memory use by 15%. The measured Designer startup time went down by 18%.

Qt 4 will not be one library, but consists of many allowing finer granulation:

• Qt Kernel lib comprising tool, io, thread classes and QObject/QKernelApplication
• Qt GUI lib with QApplication, widgets, painter
• Others libs for network, XML, SQL, openGL and other purposes

Included among the presented planned features of Qt 4 as of today are:

• Designer split up into components. This makes it possible to create a form editor plugin for KDevelop.
• Model/view classes for list box, tree view, icon view and table
• New set of classes as part of a main window/docking architecture that distinguish between dockwindows and toolbars with support for tabbed docks.
• Accessibility support for the Macintosh platform and for ATK.
• Pixmap resource system
• Several API cleanups like unifying different APIs and reducing number of concepts aim to simplify common usage, increase flexibility and remove embarassements.
• New meta object code with static read-only data block (no constructors, no cleanup handlers, no relocations, no symbols) with significantly less generated code and minimal connect() memory overhead.
• Better connect() syntax
• New cast qt_cast(const QObject*) makes string-based QObject::inherits() obsolete.
• A new class QPointer, which is successing QGuardedPtr, is lighter and faster.
• The event filters were fixed and are now called from QApplication::notify() instead from QObject::event()
• The threaded library will be the default with more thread-safety/reentrancy. Atomic refcounting makes QDeepCopy superfluous.
• In the styles section the palette and background handling has been revised: A backgroundPolicy was introduced with non-toplevel widgets inheriting their background (policy) from the parent widget. Parents can propagate their content to child-widgets. This shall essentially give (semi)transparency for widgets. And last but not least system-wide double-buffering will allow flicker free update without any hacks at all.

Qt 4 will introduce a new consistent set of light, safe and easy to use value based container tool classes which are implicitly shared and highly optimised, both for speed and memory usage. Using them will expand to less code compared to Qt 3.x and STL which will stay available for further usage together with Qt.

QString and QByteArray were both optimised for performance and memory usage besides API improvements. An important change is that isNull() is dead and will be only available in compatibility mode. Functions like latin1() will always return a valid and never a null pointer. This change led to quite some discussion and aversions among the KDE developers but Matthias pointed out that there still will be isEmpty() and operator!().

Qt 4 shall be available within a year, with a short public Beta period next year before the final release. Among the open questions Matthias addressed to the KDE developers were if KDE will switch to Qt 4 and if so when, when KDE switches who does the initial port and where, and will KDE use the opportunity to refactor some of its architecture too? In return many KDE developers will, during the hackfast week, ask Trolltech developers for additions of classes and functionality which they find long-term missing and required by KDE.

<  |  >