Using different major Qt versions



  • Hi everyone,

    We are facing an issue related to different Qt versions in a windows desktop application. The environment is simple, the IDE is visual studio, we have one solution with different projects, and everything works fine with Qt4.x.
    However the use case is the following: we want to use different Qt versions in different projects under a single solution. A dummy example would be using 5.9 in one project, and 4.8 in others, let's say the classes have Qt independent interfaces. We have managed to create a Qt5 QApplication, and other modules use Qt4 just like expected, until we reach a point where a queued connection would be necessary. We found out that despite our Qt4 signal is emitted, the connected slot does not get invoked because it lacks the Qt4 event loop - the connection returns true though.
    My question: can (and should) we use different major versions of Qt together in one single application? Can we run into other kinds of issues related to this usage?
    Thanks in advance for all your answers.
    Kind regards,
    András


  • Moderators

    @fandras90

    You can (re)compile against different major Qt versions (e.g. Qt4 and Qt5), but you may have to use #if to separate diffent sections in your code.

    However, using Qt4 and Qt5 parallel in the very same application does not sound like a good idea at all. You might be able to create a small "hello world" in doing it, but I'm even doubting this.

    My recommendation is to migrate your Qt4 completely to Qt5. I have done in the past and it was minor issue adapting some includes other other parts.



  • Hey @koahnig ,
    Thanks for your quick response! :) We would definitely migrate to Qt5 if it would be an option but unfortunately it is not, at least not all parts of the app.
    We have already managed to migrate some parts though, so it indeed works, we use different versions in the app, yet the compilation units are built against one single version without mixing. Meaning that we have some dlls that are created using Qt4 and some others that depend on Qt5. Could you please point out some reasons why using them parallel does not sound like a good idea? We are getting more and more confused about it...:)
    Thank you!


  • Moderators

    @fandras90

    I am being merely a user without enough detailed knowledge on dll interfaces.

    As long as you are having only C/C++ parameters while calling routines in those different dlls you might have a chance. However, as soon as you have Qt objects on calling lists, I doubt that this can work.

    I will bring up the topic to the attention of other mods with possible more experience.



  • @koahnig
    Yes, we were thinking about the same "might" but need to turn it into something concrete :)
    Thanks for spreading our issue, hope we will find our answer


  • Qt Champions 2016

    Just forget it. Qt has internal statics that you'll get different copies of for each of the Qt versions. This means separate event loops, separate widget window manager integrations and so on. You are not going to able to make this work, not in my lifetime.



  • @kshegunov
    That's one step forward, thanks a lot for your response!
    However this raises more questions to me. Can I find a document related to these statics somewhere? I mean, we have separable modules, we require one QMainWindow class with its event loop that would be in Qt5, and we pass some QStrings and Qt containers inside the Qt4 modules, while the modules themselves have Qt-independent interfaces for interactions between each other.
    The simplified case is the following:
    We have a dll X which is built against Qt4, and we have pure C++ interfaces to export in the dll.
    On the other hand, we have another dll Y which would use X and Qt5.
    As I understand binary incompatibility, the Qt dlls from the two different versions would not be able to distract each other, would they? So - as in my initial question - it is clearly understandable why we cannot get a Qt4 slot, with queued connection type, invoked with only running a Qt5 event loop.
    So can we handle different Qt versions as they were completely different libs (with no connections to each other even in the source code)?


  • Qt Champions 2016

    @fandras90 said in Using different major Qt versions:

    Can I find a document related to these statics somewhere?

    No. These are internal to Qt, they are inside the so/dll files and are not exported as an interface; you have no access to them whatsoever.

    I mean, we have separable modules, we require one QMainWindow class with its event loop that would be in Qt5, and we pass some QStrings and Qt containers inside the Qt4 modules, while the modules themselves have Qt-independent interfaces for interactions between each other.

    Not according to your signal-slot example in the original post. It is theoretically possible to link and work it like this only if there is no Qt shared code between the two libraries. This includes even trivial things like QString taken from one of your libraries that goes as a function argument to the other library and absolutely no GUI and QObject and QMetaObject stuff dependence that goes between the two. Basically you can make it work if one of the libraries uses only reentrant classes and functions internally, although I continue to see no point of doing it like this.

    As I understand binary incompatibility, the Qt dlls from the two different versions would not be able to distract each other, would they?

    Binary compatibility has no bearing here. Even if a given class is binary compatible, it carries with it a private part. Take a QString from one library and pass it to another (even if they're binary compatible) and you'd see all kinds of weird crashes if the private object has changed.

    So can we handle different Qt versions as they were completely different libs (with no connections to each other even in the source code)?

    In theory if the Qt calls and functionalities are completely segregated between the two. Think about it as linking two completely different frameworks.

    What you're trying to create is a centaur - half a man, half a horse - completely incompatible creatures melded into one. Ever seen one of those in real life?



  • Hi..
    My last action i have successful porting a project from qt4 to qt5.9, my basic is to make a bridge from all function wo is chance
    all file that compiler not accept have this code:

    #ifndef READONFIGOK
    #include <QtGlobal>
    #if QT_VERSION < QT_VERSION_CHECK(5, 0, 0)
    #include  "qt4config.h"
    #else
    #include  "qt5config.h"
    #endif
    #endif
    

    on qt5config.h

    #ifndef CONFIGQT5_RUN
    #define CONFIGQT5_RUN
    
    #include <QtGlobal>
    #if (QT_VERSION >= QT_VERSION_CHECK(5, 0, 0))
    #include <QMainWindow>
    #include <QApplication>
    #include <QtGui>
    #include <QFontDatabase>
    #include <QtCore/QCoreApplication>
    //// & other thing only qt5
    #define Q_WS_MAC  Q_OS_MAC
    #define Q_WS_WIN  Q_OS_WIN
    #define Q_WS_X11  Q_OS_X11
    #define Q_WS_LINUX Q_OS_LINUX
    //// swap functions
    namespace Qt {
    inline static QString stringHtmlEscapedqt5( QString x) {
        return QString(x).toHtmlEscaped();
    }
    #define escape stringHtmlEscapedqt5
    }
    #define toAscii toLatin1
    #define fromAscii fromLatin1
    
    /// debug action 
    #if 0 //// 1 or 0
    #define SCDEBUG qDebug
    #define STAGE 1
    #define _debuglogfile_                                                         \
      QString("/Volumes/dati/mim_log.txt")
    #else
    #define SCDEBUG                                                              \
      if (0)                                                                       \
      qDebug
    #define STAGE 0
    #define _debuglogfile_ QString("")
    #endif
    #endif  /// debug visual
    #define READONFIGOK
    /// debug action 
    
    #endif
    

    at end i can build all in qt4.8 & on qt5.9
    only network module have a big chance ...
    other info on: https://wiki.qt.io/Transition_from_Qt_4.x_to_Qt5



  • @kshegunov said in Using different major Qt versions:

    In theory if the Qt calls and functionalities are completely segregated between the two. Think about it as linking two completely different frameworks.

    That's the point, so despite it seems pointless, and looks like a centaur it can exist and it would work seamlessly, right? Afterwards, it is "just" an architectural problem how to separate the "completely different frameworks" - as we think of them this way in our case. So no shared code, no Qt arguments, strict line between the two.
    Thank you so much for spending your precious time on my question, I really appreciate it.



  • @patrik08
    Thanks for your reply! The issue is not related to the compile time separation of the two versions, but rather a design time decision about which one to use and how to use them in different dlls, and make them work together in one single application.
    Anyway I really appreciate your code example as it points out the differences that should be considered during a migration.


  • Qt Champions 2016

    @fandras90 said in Using different major Qt versions:

    So no shared code, no Qt arguments, strict line between the two.

    This includes, as I wrote, between the two libraries: no GUI access, no QApplication/QCoreApplication, no signal-slot connections or anything remotely related to QMetaObject. No compatible dynamic properties and QMetaType/QVariant serialization/deserialization and no (directly) compatible QDataStream writes/reads. In the end what is left is basically the containers, XML classes and strings/byte arrays/regular expressions. In my mind it would take much less time to port your code to Qt5 than to troubleshoot all the possible problems which can jump up by doing those shenanigans.



  • Totally agree with @kshegunov. Unless your Qt5 & Qt4 parts are totally and utterly separate you will have problems, and it may not be obvious at runtime where a fault lies....



  • @kshegunov
    @JNBarchan
    Thank you guys for all your input, you helped us a lot! :)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.