Using Qt5 code in Qt6
-
@Christian-Ehrlicher Why would I need two executables? Couldn’t I somehow compile the okular core as a DLL, then link Qt5 into it and create a extra layer, which maps the Qt5 to the Qt6 types?
@Creaperdown said in Using Qt5 code in Qt6:
Why would I need two executables?
Where did I wrote this?
-
@Creaperdown said in Using Qt5 code in Qt6:
Why would I need two executables?
Where did I wrote this?
@Christian-Ehrlicher My bad, I mean, why would I need to different QCoreApplications?
-
@Christian-Ehrlicher My bad, I mean, why would I need to different QCoreApplications?
@Creaperdown said in Using Qt5 code in Qt6:
why would I need to different QCoreApplications?
Because Qt5 and Qt6 are not binary compatible. How should this work? A QObject in Qt5 is different from the Qt6 one - so how should they interact with each other?
-
@Creaperdown said in Using Qt5 code in Qt6:
why would I need to different QCoreApplications?
Because Qt5 and Qt6 are not binary compatible. How should this work? A QObject in Qt5 is different from the Qt6 one - so how should they interact with each other?
@Christian-Ehrlicher I don’t need them to communicate with signals and slots or something alike. I just need it to be an isolated DLL, which gets methods called on.
My thought is to have my Qt6 application and the completely isolated library, then have a conversion layer, which doesn’t use Qt at all. This conversion layer then gets called by the application, and calls the Qt5Library, then returns a non Qt result, which is used to build a Qt6 object in the application -
@Christian-Ehrlicher I don’t need them to communicate with signals and slots or something alike. I just need it to be an isolated DLL, which gets methods called on.
My thought is to have my Qt6 application and the completely isolated library, then have a conversion layer, which doesn’t use Qt at all. This conversion layer then gets called by the application, and calls the Qt5Library, then returns a non Qt result, which is used to build a Qt6 object in the application@Creaperdown said in Using Qt5 code in Qt6:
which gets methods called on.
This will not work when these are Qt objects. The size and memory layout of Qt6 and Qt5 objects of the same class do not match. Stay at Qt5.
-
@Creaperdown said in Using Qt5 code in Qt6:
which gets methods called on.
This will not work when these are Qt objects. The size and memory layout of Qt6 and Qt5 objects of the same class do not match. Stay at Qt5.
@Christian-Ehrlicher I understand that Qt6 and Qt5 are not binary compatible, but I dont understand why this matters. As long as I dont try to assign a Qt5 type to a Qt6 type, this shouldnt matter since both live in different binaries.
Taking the example of having a QString in my Qt6 part and a method which returns a QString in my Qt5 library, which I want to call.
Why wouldnt it work, to have the Qt6 part call a extra binary, a "converter", which uses Qt5, and which calls the Qt5 library. The converter would then transform the Qt5 QString to an std::string, which it then returns, and the Qt6 application uses this to create a Qt6 QString? -
@Christian-Ehrlicher I understand that Qt6 and Qt5 are not binary compatible, but I dont understand why this matters. As long as I dont try to assign a Qt5 type to a Qt6 type, this shouldnt matter since both live in different binaries.
Taking the example of having a QString in my Qt6 part and a method which returns a QString in my Qt5 library, which I want to call.
Why wouldnt it work, to have the Qt6 part call a extra binary, a "converter", which uses Qt5, and which calls the Qt5 library. The converter would then transform the Qt5 QString to an std::string, which it then returns, and the Qt6 application uses this to create a Qt6 QString?@Creaperdown said in Using Qt5 code in Qt6:
Taking the example of having a QString in my Qt6 part and a method which returns a QString in my Qt5 library, which I want to call.
Why wouldnt it workBecause a Qt5 object is created and you return it and treat it as Qt6 object. This can't work. Stay at Qt5 until your dependencies are not ported yet.
-
@Christian-Ehrlicher I understand that Qt6 and Qt5 are not binary compatible, but I dont understand why this matters. As long as I dont try to assign a Qt5 type to a Qt6 type, this shouldnt matter since both live in different binaries.
Taking the example of having a QString in my Qt6 part and a method which returns a QString in my Qt5 library, which I want to call.
Why wouldnt it work, to have the Qt6 part call a extra binary, a "converter", which uses Qt5, and which calls the Qt5 library. The converter would then transform the Qt5 QString to an std::string, which it then returns, and the Qt6 application uses this to create a Qt6 QString?@Creaperdown said in Using Qt5 code in Qt6:
I understand that Qt6 and Qt5 are not binary compatible, but I dont understand why this matters. As long as I dont try to assign a Qt5 type to a Qt6 type, this shouldnt matter since both live in different binaries.
I don't think that you have different binaries. Even if you have one executable and one DLL they will be linked (even though dynamically at runtime) into one binary. And here is the problem: The type
QStringis the same type to the compiler/linker, both for Qt5 and Qt6. There is no way to separate the two. If those were in separate namespaces it would work as the namespace is part of the typename (I hope I'm not wrong about that). But, as you know, Qt does not use namespaces. Hence, there is no way to link two parts where one uses Qt5 and the other Qt6–neither static nor dynamic linking.If you really want to mix the two they have to be in two separate executables. With your conversion layer you are talking about you could then use remote procedure calls to call code from the other executable. Though, you will loose a lot of performance.
Best choice is to stick to Qt5 until everything is converted to Qt6.
-
@Creaperdown said in Using Qt5 code in Qt6:
I understand that Qt6 and Qt5 are not binary compatible, but I dont understand why this matters. As long as I dont try to assign a Qt5 type to a Qt6 type, this shouldnt matter since both live in different binaries.
I don't think that you have different binaries. Even if you have one executable and one DLL they will be linked (even though dynamically at runtime) into one binary. And here is the problem: The type
QStringis the same type to the compiler/linker, both for Qt5 and Qt6. There is no way to separate the two. If those were in separate namespaces it would work as the namespace is part of the typename (I hope I'm not wrong about that). But, as you know, Qt does not use namespaces. Hence, there is no way to link two parts where one uses Qt5 and the other Qt6–neither static nor dynamic linking.If you really want to mix the two they have to be in two separate executables. With your conversion layer you are talking about you could then use remote procedure calls to call code from the other executable. Though, you will loose a lot of performance.
Best choice is to stick to Qt5 until everything is converted to Qt6.
@SimonSchroeder Someone gave me the tip, that you can use -qtnamespace to compile Qt, which leads to it being automatically put into a namespace? Wouldn’t this be a solution?
-
@Creaperdown You're oversimplifying the problem. It's not just a question of source code compatibility or namespaces or dlls. There's an event queue managed by the application object. System level events are converted, handled and dispatched to Qt objects. When you schedule a connection it lands in a global per thread queue etc. etc. There are a lot of Qt's underneath mechanisms that you don't directly control. It's not just your code that handles objects, events or connections and it's not just a question of avoiding cross version assignments in your code. You will get your objects and events mixed in the "under the hood" code and it will blow up.
As others said - if you can't update everything to Qt6 stick with Qt5 and don't try to mix them. -
@Creaperdown You're oversimplifying the problem. It's not just a question of source code compatibility or namespaces or dlls. There's an event queue managed by the application object. System level events are converted, handled and dispatched to Qt objects. When you schedule a connection it lands in a global per thread queue etc. etc. There are a lot of Qt's underneath mechanisms that you don't directly control. It's not just your code that handles objects, events or connections and it's not just a question of avoiding cross version assignments in your code. You will get your objects and events mixed in the "under the hood" code and it will blow up.
As others said - if you can't update everything to Qt6 stick with Qt5 and don't try to mix them.@Chris-Kawa I see, thanks for the advise, I think thats how I'll do it
