[QML] Having different imports depending on Qt version
Hi, for GCompris (compiled in Qt5 only), we have activities using the Calendar qml object. Previously, we imported the one from QtQuick.Controls 1 but this module has been deprecated and we switched to QtQuick.Controls 2. This component hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import QtQuick.Controls"). This one is available in Qt Marketplace ( https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports Qt5 and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0") but requires QtControls private headers to be installed and they are not present on some distributions (Ubuntu < 21.04...), which we would like to still support for the next version. There is the one in Qt.labs which is available in Qt5 but not Qt6 (via "import Qt.labs.calendar 1.0"). GCompris' code works fine with any of the import ( https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calendar/Calendar.qml#L14) but I didn't find any "if(Qt_version < ...) use one, else the other" except doing a Calendar.qml.cmake with a @GOOD_IMPORT@ that would be set by cmake and a configure_file. Is there a better way? For now, we only target Qt5, so we could use Qt.labs without having to handle the other two but once we switch to Qt6, we will face the issue with distributions using Qt6.2 so I'd rather prepare this transition sooner than later. Cheers, Johnny
Re: [QML] Having different imports depending on Qt version
El dissabte, 18 de juny de 2022, a les 14:24:21 (CEST), Johnny Jazeix va
escriure:
> Hi,
>
> for GCompris (compiled in Qt5 only), we have activities using the Calendar
> qml object.
>
> Previously, we imported the one from QtQuick.Controls 1 but this module has
> been deprecated and we switched to QtQuick.Controls 2. This component
> hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import
> QtQuick.Controls").
>
> This one is available in Qt Marketplace (
> https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports Qt5
> and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0") but requires
> QtControls private headers to be installed and they are not present on some
> distributions (Ubuntu < 21.04...), which we would like to still support for
> the next version.
>
> There is the one in Qt.labs which is available in Qt5 but not Qt6 (via
> "import Qt.labs.calendar 1.0").
>
> GCompris' code works fine with any of the import (
> https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calen
> dar/Calendar.qml#L14) but I didn't find any "if(Qt_version < ...) use one,
> else the other" except doing a Calendar.qml.cmake with a @GOOD_IMPORT@ that
> would be set by cmake and a configure_file.
> Is there a better way?
>
> For now, we only target Qt5, so we could use Qt.labs without having to
> handle the other two but once we switch to Qt6, we will face the issue with
> distributions using Qt6.2 so I'd rather prepare this transition sooner than
> later.
As you have found, tou need to have two different codebases for Qt5 and Qt6.
QML doesn't have "ifdef", the only way I've been able to simulate something
like in pure QML that is having a Loader loads "the old version" and then
reacting to the Loader status changing to Loader.Error and trying to old "the
new version".
Another somewhat less ugly way way is simply having a C++ singleton or
something that tells you the Qt version and then also using a Loader to do the
same
Loader {
source: Singleton.isQt6 ? "Qt6Code.qml" : "Qt5Code.qml"
}
Cheers,
Albert
>
> Cheers,
>
> Johnny
Re: [QML] Having different imports depending on Qt version
Le dim. 19 juin 2022 à 13:05, Albert Astals Cid a écrit :
> El dissabte, 18 de juny de 2022, a les 14:24:21 (CEST), Johnny Jazeix va
> escriure:
> > Hi,
> >
> > for GCompris (compiled in Qt5 only), we have activities using the
> Calendar
> > qml object.
> >
> > Previously, we imported the one from QtQuick.Controls 1 but this module
> has
> > been deprecated and we switched to QtQuick.Controls 2. This component
> > hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import
> > QtQuick.Controls").
> >
> > This one is available in Qt Marketplace (
> > https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports
> Qt5
> > and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0") but requires
> > QtControls private headers to be installed and they are not present on
> some
> > distributions (Ubuntu < 21.04...), which we would like to still support
> for
> > the next version.
> >
> > There is the one in Qt.labs which is available in Qt5 but not Qt6 (via
> > "import Qt.labs.calendar 1.0").
> >
> > GCompris' code works fine with any of the import (
> >
> https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calen
> > dar/Calendar.qml#L14) but I didn't find any "if(Qt_version < ...) use
> one,
> > else the other" except doing a Calendar.qml.cmake with a @GOOD_IMPORT@
> that
> > would be set by cmake and a configure_file.
> > Is there a better way?
> >
> > For now, we only target Qt5, so we could use Qt.labs without having to
> > handle the other two but once we switch to Qt6, we will face the issue
> with
> > distributions using Qt6.2 so I'd rather prepare this transition sooner
> than
> > later.
>
> As you have found, tou need to have two different codebases for Qt5 and
> Qt6.
>
> QML doesn't have "ifdef", the only way I've been able to simulate
> something
> like in pure QML that is having a Loader loads "the old version" and then
> reacting to the Loader status changing to Loader.Error and trying to old
> "the
> new version".
>
> Another somewhat less ugly way way is simply having a C++ singleton or
> something that tells you the Qt version and then also using a Loader to do
> the
> same
>
> Loader {
> source: Singleton.isQt6 ? "Qt6Code.qml" : "Qt5Code.qml"
> }
>
>
Thank you for confirming there is no "clean" (as without duplicating the
code) way to do it.
I've still used the "configure_file" solution as it is the one that does
not duplicate files.
Cheers,
Johnny
> Cheers,
> Albert
>
> >
> > Cheers,
> >
> > Johnny
>
>
>
>
>
