KIO workers and the Qt5->Qt6 transition
Nicolas Fella
nicolas.fella at gmx.de
Tue Dec 12 14:57:49 GMT 2023
Hi,
this is a variant of the plugin problem outlined in
https://mail.kde.org/pipermail/kde-devel/2023-December/002234.html
TL;DR Qt6 can't load Qt5-based plugins and vice versa
This also affects KIO workers.
We have a number of sources of KIO worker plugins:
- KIO itself provides file, http, help, ftp, remote, and trash. Since
KIO is available from KF5 and KF6 we get builds of those for both Qt
versions. No problem here.
- kio-extras provides additional workers: sftp, mtp, smb, ... kio-extras
is available for KF5 and KF6, so no problem here.
- various kio-* modules, like kio-gdrive, kio-stash, kio-gopher. These
should be built for both Qts, which should generally be possible, modulo
some common files to be deconflicted
- "Applications" that ship a KIO worker as part of their offering.
Examples that come to my mind are KDE Connect that ships a kdeconnect
worker and bluedevil that ships the bluetooth and obexftp workers. These
project are generally not designed to be coinstallable. i.e. if I have
Qt6-based KDE Connect I can't use the kdeconnect worker from a KF5 app
The last case is the one giving me headaches. Possible options would be
- Ignore the problem and hope nobody misses some workers in some
applications
- Make sure all (relevant) workers are available for both Qts, adding
some complexity to the build, release, and packaging process
- Since KIO workers run out of process it should be technically feasible
to come up with a way to run KF5-based worker plugins from a KF6-based
app and vice versa. I have not tried to implement that though, and it
would require some non-trivial surgery on KIO internals
More information about the Distributions
mailing list