Skip to content

Conversation

@cordlandwehr
Copy link

This is a work in progress setup that essentially is a cleaned up revision of #121 .

Done:

  • added explicit link interface to Qt5/Qt6 variants
  • compiles and is tested against compilation of Keyboard Qt6 branch

Next:

  • runtime testing
  • test/fix coinstallability with Qt5 and Qt6 based framework

dobey and others added 6 commits December 19, 2023 15:37
Plugins and libraries are supposed to be coinstallable leading to
systems having both of them available at the same time. As a precaution
to accidential mixups of libraries that lead to hard to analyze runtime
issues due to ABI incompatibilities, always link publically against the
versioned Qt library.
This should already be default config for Qt5.
This option name is a very common practice in many projects, make it
easier to detect.
@cordlandwehr
Copy link
Author

@dobey I am now looking into the coinstallability of qt5 and qt6 version of maliit and need a little bit of input what you desire. Specifically, how do you want to name the Qt6 version? from the list of installed files I will need to add a Qt6 suffix at least for the following artifacts:

├── bin
│   └── maliit-server
├── include
│   └── maliit-2
│       ├── maliit
│       │   ├── mimserver.h
│       │   ├── namespace.h
│       │   ├── plugins
│       │   │   ├── abstractinputmethod.h
│       │   │   ├── abstractinputmethodhost.h
│       │   │   ├── abstractpluginsetting.h
│       │   │   ├── attributeextension.h
│       │   │   ├── extensionevent.h
│       │   │   ├── inputmethodplugin.h
│       │   │   ├── keyoverridedata.h
│       │   │   ├── keyoverride.h
│       │   │   ├── plugindescription.h
│       │   │   ├── subviewdescription.h
│       │   │   ├── updateevent.h
│       │   │   └── updatereceiver.h
│       │   ├── settingdata.h
│       │   ├── standaloneinputmethod.h
│       │   └── standaloneinputmethodhost.h
│       └── maliit-glib
│           ├── maliitattributeextension.h
│           ├── maliitattributeextensionregistry.h
│           ├── maliitbus.h
│           ├── maliitcontext.h
│           ├── maliitinputmethod.h
│           ├── maliitpluginsettings.h
│           ├── maliitserver.h
│           ├── maliitsettingdata.h
│           ├── maliitsettingsentry.h
│           └── maliitsettingsmanager.h
├── lib
│   ├── cmake
│   │   ├── MaliitGLib
│   │   │   ├── MaliitGLibConfig.cmake
│   │   │   ├── MaliitGLibConfigVersion.cmake
│   │   │   ├── MaliitGLibTargets.cmake
│   │   │   └── MaliitGLibTargets-debug.cmake
│   │   └── MaliitPlugins
│   │       ├── MaliitPluginsConfig.cmake
│   │       ├── MaliitPluginsConfigVersion.cmake
│   │       ├── MaliitPluginsTargets.cmake
│   │       └── MaliitPluginsTargets-debug.cmake
│   ├── libmaliit-glib.so -> libmaliit-glib.so.2
│   ├── libmaliit-glib.so.2 -> libmaliit-glib.so.2.3.0
│   ├── libmaliit-glib.so.2.3.0
│   ├── libmaliit-plugins.so -> libmaliit-plugins.so.2
│   ├── libmaliit-plugins.so.2 -> libmaliit-plugins.so.2.3.0
│   ├── libmaliit-plugins.so.2.3.0
│   ├── pkgconfig
│   │   ├── maliit-framework.pc
│   │   ├── maliit-glib.pc
│   │   ├── maliit-plugins.pc
│   │   └── maliit-server.pc
│   └── qt6
│       ├── mkspecs
│       │   └── features
│       │       ├── maliit-defines.prf
│       │       ├── maliit-framework.prf
│       │       └── maliit-plugins.prf
│       └── plugins
│           └── wayland-shell-integration
│               └── libinputpanel-shell.so
└── share
    └── doc
        ├── maliit-framework
        │   ├── *
        └── maliit-framework-doc
            ├── *

So, for me the main question is, do you want to go with "maliit3" or "maliit6" or "maliit-qt6"? For KDE we typically use the Qt major version as suffix, but there we already had that suffix aligned with the respective Qt version.
The follow question for me is, do you want co-installability only for the runtime components like executible, libs and plugins, or also for dev packages like headers, cmake modules, pkgconfig and docs?

For Qt5 versions the name is not changed, only append 6 for Qt6 builds.
This introduces a 6 suffix for each maliit library basename and that
only for Qt6 builds. Changing the library name allows to still used the
project version for incompatible SONAME changes.
@cordlandwehr
Copy link
Author

cordlandwehr commented Oct 31, 2024

This is the state with the new patch set from today (please note, I am open to any changes, dropping of patches to makes less changes in order to allow less coinstallability)

├── bin
│   ├── maliit6-exampleapp-plainqt
│   └── maliit6-server
├── include
│   └── maliit6-2
│       ├── maliit
│       │   ├── mimserver.h
│       │   ├── namespace.h
│       │   ├── plugins
│       │   │   ├── abstractinputmethod.h
│       │   │   ├── abstractinputmethodhost.h
│       │   │   ├── abstractpluginsetting.h
│       │   │   ├── attributeextension.h
│       │   │   ├── extensionevent.h
│       │   │   ├── inputmethodplugin.h
│       │   │   ├── keyoverridedata.h
│       │   │   ├── keyoverride.h
│       │   │   ├── plugindescription.h
│       │   │   ├── subviewdescription.h
│       │   │   ├── updateevent.h
│       │   │   └── updatereceiver.h
│       │   ├── settingdata.h
│       │   ├── standaloneinputmethod.h
│       │   └── standaloneinputmethodhost.h
│       └── maliit-glib
│           ├── maliitattributeextension.h
│           ├── maliitattributeextensionregistry.h
│           ├── maliitbus.h
│           ├── maliitinputmethod.h
│           ├── maliitpluginsettings.h
│           ├── maliitsettingdata.h
│           ├── maliitsettingsentry.h
│           └── maliitsettingsmanager.h
├── lib
│   ├── cmake
│   │   ├── Maliit6GLib
│   │   │   ├── Maliit6GLibConfig.cmake
│   │   │   ├── Maliit6GLibConfigVersion.cmake
│   │   │   ├── Maliit6GLibTargets.cmake
│   │   │   └── Maliit6GLibTargets-debug.cmake
│   │   └── Maliit6Plugins
│   │       ├── Maliit6PluginsConfig.cmake
│   │       ├── Maliit6PluginsConfigVersion.cmake
│   │       ├── Maliit6PluginsTargets.cmake
│   │       └── Maliit6PluginsTargets-debug.cmake
│   ├── libmaliit6-glib.so -> libmaliit6-glib.so.2
│   ├── libmaliit6-glib.so.2 -> libmaliit6-glib.so.2.3.0
│   ├── libmaliit6-glib.so.2.3.0
│   ├── libmaliit6-plugins.so -> libmaliit6-plugins.so.2
│   ├── libmaliit6-plugins.so.2 -> libmaliit6-plugins.so.2.3.0
│   ├── libmaliit6-plugins.so.2.3.0
│   ├── pkgconfig
│   │   ├── maliit6-framework.pc
│   │   ├── maliit6-glib.pc
│   │   ├── maliit6-plugins.pc
│   │   └── maliit6-server.pc
│   └── qt6
│       ├── mkspecs
│       │   └── features
│       │       ├── maliit-defines.prf
│       │       ├── maliit-framework.prf
│       │       └── maliit-plugins.prf
│       └── plugins
│           └── wayland-shell-integration
│               └── libinputpanel-shell.so
└── share
    ├── dbus-1
    │   └── services
    │       └── org.maliit.server.service
    └── doc
        ├── maliit6-framework-doc
        │   ├── *
        └── maliit-framework
            ├── *

Open points from my list:

  • port examples for coinstallability
  • port interactive tests for coinstallability
  • port qmake configs
  • test runtime (all tests above are only build system checks and tests of generated files)
  • figure out what to do with the dbus interface, because only one can be there at a time (input welcome!)

@JamiKettunen
Copy link

@dobey Any comment from your side? With Qt5 going fully EoL in 5 months (May 2025) and later distros starting to consider dropping any remaining packages depending on Qt5 still etc it'd be nice to have a way forward here followed by Maliit component releases also compatible with Qt6 (it's been nearly 2.5 years since 2.3.x) :)

CMakeLists.txt Outdated
-DMALIIT_PLUGINS_DIR="${CMAKE_INSTALL_FULL_LIBDIR}/maliit/plugins"
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit-keyboard-plugin.so"
-DMALIIT_PLUGINS_DIR="${CMAKE_INSTALL_FULL_LIBDIR}/maliit${MALIIT_LIB_SUFFIX}/plugins"
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit${MALIIT_LIB_SUFFIX}-keyboard-plugin.so"
Copy link

@JamiKettunen JamiKettunen Jan 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit${MALIIT_LIB_SUFFIX}-keyboard-plugin.so"
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit-keyboard-plugin.so"

same 2 lines below too, otherwise maliit6-server fails to load the plugin with e.g. the following since it's actually installed in /usr/lib/maliit6/plugins/libmaliit-keyboard-plugin.so:

org.maliit.framework: bool MIMPluginManagerPrivate::loadPlugin(const QDir &, const QString &) Error loading plugin from "/usr/lib/maliit6/plugins/libmaliit6-keyboard-plugin.so" "The shared library was not found."

also connection/org.maliit.server.service.in needs updating to take MALIIT_LIB_SUFFIX int account since the executable is e.g. maliit6-server

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the review! I just pushed the changes.
How to handle the dbus service file with respect to coinstallability is tricky though because this is the single file that produces a file clash between Qt5 and Qt6 version. Not sure if it is OK to just ignore it and let downstream figure out which one of them should be installed?

@cordlandwehr cordlandwehr marked this pull request as ready for review January 5, 2025 13:11
@Sodivad
Copy link

Sodivad commented Jan 13, 2025

added explicit link interface to Qt5/Qt6 variants

Is having Qt5/Qt6 be possible at the same time still relevant nowadays instead of just doing Qt6?

@JamiKettunen
Copy link

As of early 2025 the sole remaining consumer of Qt5 maliit with everything at up-to-date versions I can think of is Lomiri (formerly Unity8, the Ubuntu Touch UI) which is also available in Debian repos, but now I wonder if even it could still bring up a Qt6 maliit-keyboard while the rest of the UI remains on Qt5 for the moment (hopefully not too long).

@dobey was this the main consideration or something else? seeing the lack of timely releases if something must be pushed to a Qt5-compatible release in general it may make more sense to leave behind a compatible branch and otherwise move on similar to https://github.com/canonical/mir/tree/release/1.8, i.e. 2.3.x is Qt5 and 2.4.x is Qt6 or similar

@cordlandwehr
Copy link
Author

I also see the co-installability as a complexity increase in the build system that I personally do not see worth wrt how far all distros are with Qt6 versions. I will gladly drop all patches from this and the keyboard pull-request to only do the opt-in Qt6 porting in a way that one can only have one combination of framework+keyboard installed in Qt5 variant or in Qt6 variant.
@dobey @JamiKettunen Yet I need a statement what is expected. The current situation is really not nice that one could not even build Maliit for Qt6 even though very minimal patches are required. BTW I will also be around at FOSDEM for a chat if that makes discussion easier, just ask at the KDE booth :)

@dobey
Copy link
Contributor

dobey commented Jan 31, 2025

@dobey was this the main consideration or something else?

The input method plug-in needs to be available for any apps that still use Qt5. There are plenty of proprietary apps still using Qt5 for example. And plenty of random open source things that aren't in distros, and aren't well maintained, that some people may use. Having that available necessitates a Qt5 build of the library as well, and thus things will still need to be parallel installable, even if it was branched off before Qt6 support lands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants