KDAB contributions to Qt 5.0 (part 2)

Continuing the series on KDAB contributions to Qt 5.0, this time we cover some platform support and containers.

Containers improvements

The containers in Qt 5 recieved many improvements compared to their Qt 4 versions. Due to concerns of binary compatibility, such changes can only be undertaken for new major releases of Qt, but still there is a need to be conservative in what is changed.

The part KDAB played in improving the Qt containers was mainly in making small changes for consistency, adding C++11 dependent features, giving the compiler more hints for optimizations, and making it more difficult to accidentally misuse the containers. Several of the issues raised by Marc Mutz regarding the Qt containers were fixed by Marc as part of KDABs investment into Qt 5.

In particular, many types in Qt have been marked with the Q_DECLARE_TYPEINFO macro as PRIMITIVE, or MOVABLE as appropriate. All QFlags are now automatically marked as Q_PRIMITIVE_TYPE, using a partial template specialization. This makes the Qt containers like QList perform better when used with flag types 'for free' in Qt 5. Partial template specialization is a C++ language feature which enables some of the metatype features I mentioned yesterday.

Similarly, all Qt containers which take a single template argument (QList, QVector etc) have been marked as Q_MOVABLE_TYPE using a partial template specialization. QPair in particular received a somewhat more complex optimization which accounts for both types it contains and determines whether it should be treated as a PRIMITIVE, MOVABLE or COMPLEX type. This means it is more efficient to put containers into containers, though in terms of API that is often not advised. Many other types in Qt have been marked as PRIMITIVE or MOVABLE as appropriate where that was not the case before, so in general, this helps performance of Qt containers. Also for performance reasons, QVector is now used instead of QList where it is a more suitable container.

C++11 compatibility is also something KDAB has worked a lot on in Qt 5. All of the Qt containers have been extended with cbegin() and cend() API for compatibility with new C++ containers, and the QVarLengthArray class received a bugfix similar to a fix in the C++11 standard containers.

There are many more improvements to the Qt containers, such as C++11 move assignment and move constructors, but this blog series is focussing specifically on contributions from KDAB.

Qt 5 WinCE maintenance

Since gaining extensive experience with Qt on WinCE during the Kontact Touch development, KDAB has been helping others solve their problems related to Windows embedded platforms, such as WinCE, and Windows Embedded Compact 7.

Since the launch of Qt Project we have also been working to ensure that Qt 5.0 would be a quality release, and a quality foundation for the future, where embedded Windows is concerned. Since very early in Qt 5 development, we have been working on creating demos using Qt 5 and QtQuick 2 on WinCE, and solving the platform abstraction issues associated with that.

The patches required to keep the WinCE port up to date cover a wide range of areas. At the most fundamental level, the buildsystem of Qt has needed some updates to function properly for WindowsCE. Because it is common to strip down embedded systems to a bare minimum, certain features which are usually available in Qt such as printer support and clipboard support are not usually available from WindowsCE, and so have to be compiled out of Qt too. Another fundamental requirement of the WindowsCE work is ensuring that the dependencies of Qt, such as zlib, can be made to work properly on WindowsCE. More significantly, the v8 javascript engine needed to be ported to WindowsCE. That port was successful, which means that QML2 can work with WindowsCE, just as on any other platform.

At the platform level, Qt 5 also required some work for WindowsCE. A common problem when implementing Qt 5 on WindowsCE is that the WindowsCE operating system does not have all of the functionality usually expected from Windows when using the desktop APIs. Specific code is required for handling of temporary files, network sockets, starting, stopping and interacting with processes etc. This kind of low-level work allows Qt to provide the same familiar platform abstractions on WindowsCE as are provided on all other platforms.

On the gui level too, there are differences in how window management must be handled, such as decoration, painting, and moving windows as well as handling fullscreen mode. Pixmaps and fonts can required WindowsCE specific handling in Qt 5 too, with the result that all the benefits of distance fields used for font rendering reach WindowsCE too. A requirement for the distance fields feature in the font rendering is that a vector outline of glyphs must be available. WindowsCE does not provide that as an operating system feature, so the FreeType library is used directly on WindowsCE for that feature instead.

Part of the work was catching up with the Qt modularisation process. Some parts of the WindowsCE code needed to be split between the QtWidgets and QtGui module to make QtQuick2 applications work properly.

Mac platform support

KDAB took on responsibility for improving the Mac port of Qt 5 and particularly the native API integration.

By adding an abstraction to QPA for menus, it was possible to implement that abstraction on Mac using the native APIs for menus on that platform. Mac menus are natively separated from the windows on screen that they relate to, while this was also possible in Qt 4, the code no longer worked after porting to Qt 5/QPA.

Related to the native Mac menu implementation, KDAB also implemented the abstraction and Mac-implementation for the systemtray. Systemtray entries typically show menus, and can use native integration for the menus and icons. The QSystemTray implementation is now implemented in terms of the platform-abstraction.

For greater native integration, platform-specific drag API is also now used on Mac. This is another area where QPA and use of native APIs can really make a difference - typical Mac applications have well defined default actions during drag operations (eg copy versus move), different behavior depending on whether shift/ctrl modifiers are used, This also paves the way for more asyncronous drag handling in Qt-on-Mac applications.

On the Mac 10.7 (Lion) operating system, scrollbars are typically hidden and inside the scroll-area until the mouse moves into a position to use it. Here again, native MAC APIs can be easily used, thanks to QPA, to implement styling and behavior of the scrollbars in a consistent way.

Native APIs are now also being used in Qt 5 for opening documents and URLs, allowing integration with the users preferences