Getting Qt application to honour dark theme on Lubuntu 26.04.1
-
Hmmm. I tried copying the system version of the plugin to my plugins/platformthemes directory and Qt didn't try to load it.
I then tried
export QT_QPA_PLATFORMTHEME=lxqtand got:qt.core.plugin.factoryloader: looking at "libqtlxqt.so" qt.core.plugin.loader: Found metadata in lib /opt/DeepSkyStacker/plugins/platformthemes/libqtlxqt.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformThemeFactoryInterface.5.1", "MetaData": { "Keys": [ "lxqt" ] }, "archlevel": 1, "className": "LXQtPlatformThemePlugin", "debug": false, "version": 395776 } qt.core.plugin.factoryloader: Got keys from plugin meta data QList("lxqt") qt.core.plugin.factoryloader: checking directory path "/opt/DeepSkyStacker/platformthemes" ... qt.core.library: "/opt/DeepSkyStacker/plugins/platformthemes/libqtlxqt.so" cannot load: Cannot load library /opt/DeepSkyStacker/plugins/platformthemes/libqtlxqt.so: /usr/lib/x86_64-linux-gnu/libQt6Svg.so.6: undefined symbol: _ZN14QObjectPrivateC2E16QtPrivate_6_10_2, version Qt_6_PRIVATE_API qt.core.plugin.loader: QLibraryPrivate::loadPlugin failed on "/opt/DeepSkyStacker/plugins/platformthemes/libqtlxqt.so" : "Cannot load library /opt/DeepSkyStacker/plugins/platformthemes/libqtlxqt.so: /usr/lib/x86_64-linux-gnu/libQt6Svg.so.6: undefined symbol: _ZN14QObjectPrivateC2E16QtPrivate_6_10_2, version Qt_6_PRIVATE_API"so this is definitely above my salary level :(
David
-
Hi,
You need to build that plug-in with the Qt version you use to build your application. What happens is that you have Qt 6.10.0 loaded in memory for your application but that plug-in was built for 6.10.2.
-
@SGaist That makes sense, but OTOH I'd much prefer that Qt delivered it as part of the Qt distro ... and automatically searched for it. Hence the problem report I opened.
D.
-
So you are saying that the plugin for e.g. kde is part of Qt, and that you think it’s viable for me to tell my users to do their own build of the plugins, or that you think that I should build and ship them with my product??
The only way that makes sense to me is for Qt to ship them.
As things stand, the theme support just doesn’t work for any Lubuntu users.
-
So you are saying that the plugin for e.g. kde is part of Qt, and that you think it’s viable for me to tell my users to do their own build of the plugins, or that you think that I should build and ship them with my product??
The only way that makes sense to me is for Qt to ship them.
As things stand, the theme support just doesn’t work for any Lubuntu users.
@Perdrix said in Getting Qt application to honour dark theme on Lubuntu 26.04.1:
The only way that makes sense to me is for Qt to ship them.
Again: it's a third party plugin. How can Qt ship this at all? Ask your distribution to ship it as this is the right place.
-
So you are saying that the plugin for e.g. kde is part of Qt, and that you think it’s viable for me to tell my users to do their own build of the plugins, or that you think that I should build and ship them with my product??
The only way that makes sense to me is for Qt to ship them.
As things stand, the theme support just doesn’t work for any Lubuntu users.
@Perdrix said in Getting Qt application to honour dark theme on Lubuntu 26.04.1:
I should build and ship them with my product??
It looks like you already ship a copy of Qt and its official plugins. So, it makes sense to ship a copy of the 3rd-party plugin of interest too, right? @IgKh already found the source code for you in an earlier post, which contains compilation instructions.: https://github.com/lxqt/lxqt-qtplugin
Alternatively, you could make your application depend on the distro's copy of Qt instead of your own copy. That way, the app can also load the distro's copy of libqtlxqt.so
-
Alternatively, you could make your application depend on the distro's copy of Qt
That wouldn't work on most Linux distros, and the installed Qt would need to exactly match the verison of Qt I built my application with.
@Perdrix said in Getting Qt application to honour dark theme on Lubuntu 26.04.1:
That wouldn't work on most Linux distros, and the installed Qt would need to exactly match the verison of Qt I built my application with.
An exact match is not needed. Qt promises compatibility: If you build your application with an older version of Qt 6, then users can run it with a newer version of Qt 6.
There have been times when compatibility was accidentally broken. When this happens, it is treated as a critical bug and all effort will be made to restore compatibility (example: https://qt-project.atlassian.net/browse/QTBUG-135578 )
Anyway, building and shipping libqtlxqt.so remains a valid solution.
-
A different post I replied to surfaced a different idea: On Linux we are distributing our app as AppImage. This will package all dependencies into an executable image. It is not the ideal solution for Linux, but if you have a small software that is not included in official repositories of the distros it is the much better option for maintainability. This would package both Qt and libqtlxqt alongside your app. It also does not require any special installation. Though, once you go down that path it is quite easy to register your app through xdg.
Here is roughly how we deploy our AppImage:
#!/bin/bash LD_LIBRARY_PATH= # additional library paths if required export LD_LIBRARY_PATH chmod u+x linuxdeploy*.AppImage # on CI/CD this might not have the executable flag when checked out export VERSION=1.0.0 echo == Remove old AppDir. == rm -rf AppDir echo == Generate new AppDir. == ./linuxdeploy-x86_64.AppImage --appdir=AppDir --executable=../release/MyApp --desktop-file=MyApp.desktop --icon-file=MyApp.svg echo == Bundle Qt libs and create AppImage. == cd AppDir ../linuxdeployqt-6-x86_64.AppImage MyApp.desktop -qmake=/path/to/qmake -appimage echo == Done. ==You'll see that we use both
linuxdeployandlinuxdeployqt. This is at least what worked for us. These tools require you not to use the newest version of Linux because they want to ensure broad portability.I guess that LGPL conformance is given because the AppImage is just a regular image that can be mounted regularly and thus someone might be able to exchange the libraries inside it.
Just for completeness sake: Besides AppImage there is also Snap and Flatpack. My research at the time brought me to AppImages.