The main problem I see is the KRecentDocuments integration.

In T13590#239321, @dfaure wrote:

The main problem I see is the KRecentDocuments integration.

We could replace using KRecentDocument directly and use the DBus interface provided by https://invent.kde.org/plasma/kactivitymanagerd/-/blob/master/src/service/Resources.h
This would make the recent document saving a runtime thing.

Blockers for moving down:

MimeTypeFinderJob
OpenWithHandlerInterface
UntrustedProgramHandlerInterface
desktopexecparser
krecentdocument

The first 4 should move to KService too, IMHO.

KRecentDocument is the main problem.

In T13590#295618, @dfaure wrote:

The first 4 should move to KService too, IMHO.

KRecentDocument is the main problem.

We have a task for this https://phabricator.kde.org/T14236

It could already move to KService.

In T13590#295618, @dfaure wrote:

The first 4 should move to KService too, IMHO.

KRecentDocument is the main problem.

That's not easily achievable though. e.g. MimeTypeFinderJob uses KIO::TransferJob, so it drags the whole worker stuff with it.

Oh I see. Right, then MimeTypeFinderJob definitely stays in KIO.

Which means either

• nothing moves, or
• KIO::ApplicationLauncherJobPrivate::showOpenWithDialogForMimeType has to use QMimeDatabase instead, for local files, meaning we lose the ability to say "always open this type of file with this app" in the open-with dialog for remote files, or
• KIO::ApplicationLauncherJob has to be split in two, the case "service is null, show open-with dialog" stays in KIO (new job), the case "service is not null, just start it" moves down to KService (note that there are two ways for the service to be null currently: the first constructor with nullptr as argument, and the third constructor). So this creates a porting trap (the future class would assert that the service is not null). To be checked as part of the porting away from the "KIO::" namespace in the apps (if the service can be null, add an if() to select the right job).