Add support for Qt6 as well as Qt5

[dobey]

This reverts the text-input-v2 support back to text-input-v1 as well, as the pre-built headers from Qt may not be available on all systems in Qt6. To build for Qt6, one needs to pass -Dwith-qt6=ON to cmake.

[aleasto]

Looking forward to test this in fedora as soon as keyboard is also ported :)

[bhush9]

There is no compositor currently with text-input-v1 support.

EDIT: apparantly I was wrong, kwin does seem to support it still.

[dobey]

kwin does seem to support it still.

As does Mir 2.x now too.

[cordlandwehr]

Hi, I would like to ask about the state of these changes? Getting them merged would help with downstream packaging to provide a Qt6 version.

[pvuorela]

I'm having trouble building the Qt6 version, build fails on settingdata.cpp. But Qt5 passes and this has been pending for long so I'll just approve. Not sure should the settingdata thing exist anymore. There was some settings support earlier which has generally been removed ages ago.

For one small detail it could be nice having some rationale documented on the commit reverting the wayland protocol version.

[dobey]

I'm having trouble building the Qt6 version, build fails on settingdata.cpp.

@pvuorela Were you building with -Werror or did a newer Qt6 remove some of the deprecated calls? It compiles, but with deprecation warnings, for me, on Debian Testing, which still has 6.4.2.

[pvuorela]

Didn't do any special flags, just enabling qt6. Having Fedora 40 & Qt 6.7.1.

[  1%] Building CXX object CMakeFiles/maliit-common.dir/common/maliit/settingdata.cpp.o
In file included from /usr/include/qt6/QtCore/QMetaType:1,
                 from /home/pvuorela/tila/src/maliit/framework/common/maliit/namespace.h:17,
                 from /home/pvuorela/tila/src/maliit/framework/common/maliit/settingdata.h:15,
                 from /home/pvuorela/tila/src/maliit/framework/common/maliit/settingdata.cpp:12:
/usr/include/qt6/QtCore/qmetatype.h: In instantiation of ‘constexpr bool QtPrivate::checkTypeIsSuitableForMetaType() [with X = QList<Maliit::PreeditTextFormat>]’:
/home/pvuorela/tila/src/maliit/framework/common/maliit/namespace.h:176:1:   required from here
  176 | Q_DECLARE_METATYPE(QList<Maliit::PreeditTextFormat>)
      | ^~~~~~~~~~~~~~~~~~
/usr/include/qt6/QtCore/qmetatype.h:1183:51: error: static assertion failed: Meta Types must be fully defined
 1183 |         static_assert(is_complete<T, void>::value || std::is_void_v<T>,
      |                                             ~~~~~~^~~~~~~~~~~~~~~~~~~~
/usr/include/qt6/QtCore/qmetatype.h:1183:51: note: ‘(((bool)std::integral_constant<bool, false>::value) || ((bool)std::is_void_v<QList<Maliit::PreeditTextFormat> >))’ evaluates to false
/home/pvuorela/tila/src/maliit/framework/common/maliit/settingdata.cpp: In function ‘bool {anonymous}::checkValueDomain(const QVariant&, const QVariant&)’:
/home/pvuorela/tila/src/maliit/framework/common/maliit/settingdata.cpp:20:31: warning: ‘bool QVariant::canConvert(int) const’ is deprecated [-Wdeprecated-declarations]
   20 |         if (!domain.canConvert(QVariant::List))
      |              ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
In file included from /usr/include/qt6/QtCore/QVariant:1,
                 from /home/pvuorela/tila/src/maliit/framework/common/maliit/settingdata.h:18:

And the canConvert warning part repeating a few times more.

[dobey]

Didn't do any special flags, just enabling qt6

Hrmm. Debian Testing just got 6.6.2, and I don't see the error there with a clean build. I did get it with a dirty build, though. So seems like maybe something getting tripped up with moc perhaps?

Anyway, I think this branch also need to be tweaked to install the shared libs as different library names for qt6 and qt5 as well. Maybe a good time to break ABI and remove the SettingsData stuff too then?

[pvuorela]

Apparently the rather unhelpful compiler was about this #123

With that I got the build a bit forward, eventually failing with

[ 20%] Linking CXX shared library libmaliit-plugins.so
/usr/bin/ld: libmaliit-common.a(settingdata.cpp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: failed to set dynamic section sizes: bad value

Seems strange, didn't investigate yet further.

Maybe a good time to break ABI and remove the SettingsData stuff too then?

At least removing the validateSettingValue() could be an option, even if the above error it wasn't really about the settingdata. Or if kept, I'm not sure why is it on the public API at all.

For usage the mimpluginmanager.cpp propagates handleExtendedAttributeUpdate() to both attributeExtensionManager (MAttributeExtensionManager) and sharedAttributeExtensionManager (MSharedAttributeExtensionManager) where only latter used the validation. The attributes are involved in app specific overrides like enter key customization in MInputContext::updateInputMethodExtensions(). But now, is that latter shared thing actually used for anything? I'm spotting mostly mimpluginamanager connecting signals to some handlers on it, but not much else.

[pvuorela]

Seems strange, didn't investigate yet further.

FWIW got qt6 build through by adding to CMakeLists.txt

set_property(TARGET maliit-common PROPERTY POSITION_INDEPENDENT_CODE ON)
set_property(TARGET maliit-connection PROPERTY POSITION_INDEPENDENT_CODE ON)

I'm puzzled why Qt5 was fine without it.

[cordlandwehr]

@pvuorela as far as I know Qt6 does not set -fPIC unconditionally anymore. a related discussion of those issues e.g. can be found here, https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/222

[pvuorela]

@pvuorela as far as I know Qt6 does not set -fPIC unconditionally anymore. a related discussion of those issues e.g. can be found here, https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/222

Ah, that would explain it. Thanks for the link.

@dobey maybe you could add the PIC options and get this merged? Suppose those shouldn't harm even on qt5 version(?)

[cordlandwehr]

I would like to ask about how to proceed with adding Qt6 support. This MR is now marked as a draft and there is another MR with #122 that unconditionally switches to Qt6. I would like to see at least this PR merged because it improves packaging situation downstream to have a clear patch with patches to use.
If there are additional steps/work to be done for providing an optional Qt6 build flag, please tell me an I can also help out.

[dobey]

I would like to ask about how to proceed with adding Qt6 support.

At the very least, this branch needs work to enable parallel installing of builds with both Qt5 and Qt6 support. It shouldn't be difficult to do, but I haven't had a chance to do it yet, which is partly why I put this PR back into draft mode.

[cordlandwehr]

Ok, that's something I can help with. I will start with cleaning up my patch series also for Keyboard and create a draft merge request so that we have something to test integration with.