0 votesclick to vote up

David Sugar: Qt 5 migration notes Published Jan 27 2013 via RSS

planetUbuntu Planet Ubuntu 4 Afghanistan Last visit Jan 1 2011 0 Friends 0 Groups More info Send a message Add as friend Other contents

I wanted to write a little about our effort to migrate to Qt5. It has been said that Qt5 is 99% compatible with Qt4 sources, and this indeed is true. However, it is the 1% that is still often not explained or sufficiently documented. Furthermore, in my particular case, I wanted to migrate code that can then build under both Qt4 and Qt5, and to do so with cmake, which is not explained at all.

My reasons for this are simple. I often build a binary package that works on different distribution releases. I do not want to go through the trouble of separately maintaining different package metas for each and every debian or ubuntu release. In the future Qt5 will displace Qt4, but things like Ubuntu LTS and Debian stable releases that use Qt4 will continue to be maintained for years after this. Hence I want to make sure this happens without having to split either my packaging or my sources.

In Qt itself, source practices like not using _WS OS defines, or already identified depreciated features, make it easy to recompile Qt4 applications with Qt5. There is one important exception. Things that used to use <QX11Info> are now entirely gone in Qt5.

It happens I was using QX11Info for one thing; I needed the X11 display handle so that I could call libxss, the screensaver library. I wanted to know when the xscreensaver was active and to track input idle time, and I did not find a better way to do this other than calling the X11 screensaver extension lib. If someone knows a better way I would be happy to hear it.

However, it is easy to come up with a valid alternative. What I eventually came up with was something like:

#ifdef HAVE_LIBXSS
#if QT_VERSION >= 0x050000
#include <qpa/qplatformnativeinterface.h>
#else
#include <QX11Info>
#endif
#include <X11/extensions/scrnsaver.h>
#endif

To get the correct headers whether Qt4 or Qt5. And to get the native display handle:

#if QT_VERSION >= 0x050000
    QPlatformNativeInterface *native = QGuiApplication::platformNativeInterface();
    if(!native)
        return false;
    Display *display = static_cast<Display *>(native->nativeResourceForWindow("display", NULL));
#else
    Display *display = QX11Info::display();
#endif

CMake was a little tricker. First, the Qt5 specific macros are different from the Qt4 ones. Also, they are not in regular use yet. In any case, I wanted a CMakeLists.txt that behaved correctly for both Qt4 and Qt5. I eventually found I could extend the existing Qt4 cmake macros to support Qt5 directly.

find_package(Qt4 4.8.0 REQUIRED)
if(QT4_FOUND)
    if(QTVERSION VERSION_GREATER "4.99.99")
        set(QT5_FOUND true)
    endif()
    include(${QT_USE_FILE})
    ADD_DEFINITIONS(-DQT_GUI_LIBS -DQT_CORE_LIB)
    include_directories(${QT_QTCORE_INCLUDE_DIR} ${QT_QTGUI_INCLUDE_DIR} ${QT_QTGUI_INCLUDE_DIR}/../QtWidgets ${QT_QTGUI_INCLUDE_DIR}/${QTVERSION}/QtGui)
    if(QT_IS_STATIC)
        file(GLOB QT_PLUGINS ${QT_PLUGINS_DIR}/codecs/*${CMAKE_STATIC_LIBRARY_SUFFIX})
    endif()
    ...

The idea of adding the extra include paths for Qt5 relative is because the standard Qt4 paths already are correct for the cmake ran qmake instance being invoked. Adding the extra paths has no effect on Qt4. Also, the extra linkage for Qt5 has to be accounted for:

if(QT5_FOUND)
    find_library(QT5_WIDGETS NAMES QtWidgets HINTS ${QT_LIBRARY_DIR})
    set(QT_LIBRARIES ${QT_LIBRARIES} ${QT5_WIDGETS})
endif()

Indeed this all works and will produce a CMakeLists.txt that does the correct thing for both Qt4 and Qt5, at least for applications that of course use widgets. One additional problem is in includes.

In Qt4 one needed to only

#include <QtGui>

to get all the Qt widget classes included. Sloppy, but sometimes useful for simplicity. In Qt5, one has to now use that and

#include <QWidget>

. However, this no longer seems to include ALL the classes like in Qt4, just "most" of them. The rest have to be manually included. In particular things like QDialog, surprisingly, were left out. However, adding the additional includes do not in any way break Qt4. So again, we end up with code that configures and compiles, both for Qt4 and Qt5, and actually pretty painlessly like claimed.