Nextcloud ships such a plugin: https://github.com/nextcloud/desktop/blob/master/shell_integration/dolphin/ownclouddolphinoverlayplugin.cpp

Interesting, is there any reason it does not use KPluginfactory like the rest of KDE does?

And considering that it is only used in dolphin could it make sense to move it there?

Makes sense, unless we want those overlays to show up in the file dialog too, in the future...

I don't see how that is currently the case, also similar to T12174 I think from a dependency POV it does not seem desirable for most consumers.

Keep in mind that there are more file managers than Dolphin. There's at least Krusader and Index. No idea whether they use this, but it's not that far fetched

It might be worth noting that the code which loads/uses the plugins (KFileItemModelRolesUpdater class) is also purely dolphin internal.

No idea whether they use this, but it's not that far fetched

No they don't, I checked that with an lxr search before creating this task.

What do we gain by removing it from KIO?

Then it would be moved to the only place it is used: Dolphin. This way KIO will be lighter. Also it seems like the header does not contain any KIO specific classes, if we move it to dolphin one would only need to depend on the dolphin headers & Qt instead of KIO and it's dependencies.

As discussed in the weekly, KIO feels like a weird place, but there isn't any better one.
The class should be moved from KIOWidgets to KIOCore to make life easier for third parties that provide such a plugin

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

KAbstractFileItemActionPlugin and KFileItemActions should be considered as well then.

KRecentDirs seem like an old features that can be removed.
As far I can tell, its only user is KFileWidget which has never a "m_fileclass" set which is necessary for its feature to work.

We have KRecendDocument and KActivitiesStats that can provide alternative feature.

KAbstractFileItemActionPlugin and KFileItemActions should be considered as well then.

No, those are used in other places like plasma as well.

As far I can tell, its only user is KFileWidget which has never a "m_fileclass" set which is necessary for its feature to work.

that is not true, please see the code in KFileWidgets:
QUrl KFileWidget::getStartUrl(const QUrl &startDir, QString &recentDirClass, QString &fileName)
Here we get the value by reference and assign it within the function.

In T14538#287784, @alex wrote:

As far I can tell, its only user is KFileWidget which has never a "m_fileclass" set which is necessary for its feature to work.

that is not true, please see the code in KFileWidgets:
QUrl KFileWidget::getStartUrl(const QUrl &startDir, QString &recentDirClass, QString &fileName)
Here we get the value by reference and assign it within the function.

I stand corrected ;-)