Well, if everything goes according to plan, *all* servicetypes will disappear, even the servicetype concept itself :-)

That would mean that desktopfile-only services like in https://cgit.kde.org/plasma-desktop.git/tree/kcms/kfontinst/apps/installfont.desktop would no longer be possible, right? One would need to write a C++ plugin.
That would be at least a bit sad

Right, we are going too far. What we want to deprecate is desktop files pointing to c++ plugins.
And therefore the class that loads such plugins.

We need to keep desktop files for pop-up menu actions like this one. And therefore KServiceTypeTrader... That's what Dolphin uses, right?

It is indeed. This is making me reconsider the plan to drop KServiceTypeTrader :(

Or maybe I should rename KApplicationTrader to KServiceTrader in order to have only one trader class, and add a queryByServiceType method for the dolphin use case.

The alternative is to install all KonqPopupMenu/Plugin desktop files together into a specific dir, and let dolphin parse them from scratch. But that's ugly and slow when we have a nice cache with a nice API.

The alternative is to install all KonqPopupMenu/Plugin desktop files together into a specific dir, and let dolphin parse them from scratch. But that's ugly and slow when we have a nice cache with a nice API.

KRunner does sth. similar like this, but there they are in most cases parsed only once in the lifetime of the RunnerManager. But that suggestion also implies that it should be removed from the framework, have I understood this correctly?

Seems sensible. I think what you mean is that I posted my thoughts into the wrong task, 16 months ago, that's quite possible :)

But then we would still need to use KServiceTypeTrader which supposed to go away in T12179 🤔

No, you don't. The code in KFileItemActions says:

 const auto jsonPlugins = KPluginLoader::findPlugins(QStringLiteral("kf5/kfileitemaction"), [&db, commonMimeType](const KPluginMetaData &metaData) {
     if (!metaData.serviceTypes().contains(QLatin1String("KFileItemAction/Plugin"))) {
         return false;
     }
     ....
}

In other words, the plugins are installed into a specific subdir (which is how we do the "filtering"), and in addition (for some reason....) we check the servicetype in the JSON metadata.

No desktop file is needed anymore.

Okay now all makes sense :D Then the task is not at all about the KonqPopupMenu/Plugin service type.