Actually, if KCMUtils is trimmed down, maybe its own dependencies (and tier?) can be trimmed down? Then it would be even less of a problem for KIO to depend on it...

What would be the issue? A tier3 framework can depend on another tier3 framework.
And KCMUtils doesn't depend on KIO, so KIO can depend on KCMUtils.
It's however a bit "sad" to add more dependencies to KIO, people tend to find it has too many already.....

It's probably time to remove support for Type=Device desktop files. People just don't mount devices that way anymore.
In the very old days, this was the way to mount a CDROM or floppy. But those got replaced with USB devices, which magically show up in plasma.
And then this means removing KDevicePropsPlugin indeed.

I'll call it KTerminalLauncherJob so it can move out of KIO without further renaming.

kdesvn: https://invent.kde.org/sdk/kdesvn/-/merge_requests/1
arkpart: https://invent.kde.org/utilities/ark/-/merge_requests/40
kfontviewpart: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/771
kigpart.so: https://invent.kde.org/education/kig/-/merge_requests/3
kmplotpart.so: https://invent.kde.org/education/kmplot/-/merge_requests/3
libcantorpart.so: https://invent.kde.org/education/cantor/-/merge_requests/30

One solution is to just move the kpartsplugins/ loading code to Konqueror.
The other is to implement a whole new plugin mechanism.
Unless someone is interested in redesigning the whole mechanism, I'd say we should go with "moving" the code (copying and deprecating).
Opinions?

Ah, co-installability, good point. Then we're back to: ECM can't know what the app wants, the app needs to ask for it, or (for the transitional period) the developer could ask for it, to test things. => KDEInstallDirs5, KDEInstallDirs6, and a KDEInstallDirs that forwards to KDEInstallDirs5 by default, and to KDEInstallDirs6 if a cmake option is set.

Ah, I see. I was thinking of ECM as a completely independent module, but you're right, as part of frameworks it will get a KF6 branch.

kio !396 is in, the final cleanup and move is for after KF6 branching

The kdepim parts are loaded by name from KontactInterface::Core::createPart, which does e.g. KPluginLoader("kmailpart"), which resolves to PREFIX/lib64/plugins/kmailpart.so. I think that means it's all fine, they can keep living there. Nothing needs to iterate over kdepim parts, so no need to move them to a subdir.

Interesting about desktopexecparser. I always assumed it would just move along with CommandLauncherJob/ApplicationLauncherJob/kprocessrunner.

Actually, this doesn't really make sense, given that WebEnginePart doesn't use KIO.

My thoughts on that code are the following: T14307. But actually I just realized something.... I'll add a comment there.

I think it will have to move all to KIOGui because of the KIconLoader usage.

https://invent.kde.org/frameworks/kio/-/merge_requests/396

Indeed.

Sounds reasonable. Are you volunteering to write that API? My interest in all this stops at "making it build with Qt 5.15" :)

KRun is fully done.
KDirModel (with KDirLister and FileUndoManager) is on-going in T11821.
Core/Gui split for KUriFilterPlugin is handled in T14306.

@skelly From what I understand, the problem with versionless targets is when they "leak" into generated FooConfig.cmake files, and then users can end up with bad mix-and-match.

My thoughts during the meeting: extracting the qt-specific install dirs from KDEInstallDirs. Then apps would be able to choose between include(QtInstallDirs5) and include(QtInstallDirs6).

I volunteer to write these jobs, but I'm having second thoughts about providing a replacement in KIOGui for API in KService. It *raises* the amount of needed dependencies.

I locally attempted the move to kiogui, to see what would create problems.

https://invent.kde.org/frameworks/kio/-/merge_requests/387

It seems clear to me that only konqueror uses the KParts Plugins feature:

Yes that would make sense, as a first step before I toggle it for good in KIO.
In theory it should all be fine :)

Better plan, let KCoreDirLister emit error(KJob*) and handle that in apps and in KDirModel.

It would appear that I grepped wrongly, sorry about that.

Notes from the KF6 sprint (2021-03-28)

kio_trash can probably just exec() the job, a blocking call is fine there.

After filtering out the unrelated results from lxr, I see only these:

KIOCore dependencies:

• Remove KDBusAddons once kdeinit is removed, it was only used for KDEInitInterface. T14310
• Move DesktopExecParser up to KIOGui to remove the dependency on KService. T14309
• Remove KProtocolManager::defaultUserAgentFromPreferredService and hardcode WebEnginePart instead of KHTML. T14307

Next issue: KDirModel uses KDirLister (which extends KCoreDirLister with QWidget* and KMessageBox for errors).
Idea: take a JobUiDelegate in KCoreDirLister, remove KDirLister, rename KCoreDirLister to KDirLister.
And set the ui delegate from the factory automatically like in KIO jobs.

I'm confused. ECM does not call find_package(Qt<n>) at all right now. So no change there. For KF6 all we need is search/replace on the REQUIRED_QT_VERSION variable.

I'd say the first step is to port KIO away from it

Using the job is preferred (where the KIO dependency can be kept) because it won't block.

KF6 meeting notes:

Meeting notes from the KF6 sprint:

Cleanups needed: removing the last uses of kf5_add_kdeinit_executable ==> T14298

In the KF6 sprint today it was said that I took care of kdepim, but that's not the case. That was for kontact plugins (e.g. D28608), not for the KParts.

Created a separate task for KRecentDocuments: T14236

@stefanocrocco @marten Any input on which of the two proposals sounds best to you?

Should KRecentFileAction be based on a core-only class like KRecentDocuments?