[QML] Having different imports depending on Qt version

[Johnny Jazeix]

Le dim. 19 juin 2022 à 13:05, Albert Astals Cid <aacid at kde.org> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20220619/38cf0787/attachment.htm>