Another observation:

Many applications save their recent files in their *rc file which is problematic since it's mixing config and state. New KRecentFileAction API should encourage to separate this better

The main usage of saveEntries/loadEntries seems to be in combination with KSharedConfig::openConfig()->group(QLatin1String("Recent Files"))
The new API should simplify that use case by determining a suitable filename (similar to KSharedConfig) in a suitable location (XDG_DATA_DIR or whatever comes out of the XDG_STATE_DIR discussion)

The only exceptions to this that I've seen is KDevelop storing both recent files and projects and Kate storing per-session recent files. Both cases can be covered by allowing groups in aforementioned file

My current thinking on config vs state, is that for things you wouldn't want in a VCS, XDG_DATA_DIR is just fine. I'd put window sizes and recent files there.

We could have a KSharedConfig()::openStateConfig() in order to make it easy to store things there. Well, in fact we almost have that already, as

KSharedConfig::openConfig(QString(), FullConfig, QStandardPaths::AppDataLocation);

which doesn't read well, so openStateConfig() would make sense, it would simply be implemented by a call to the above. And this encapsulates the location, in case XDG ever comes to a different conclusion.

Having a KSharedConfig()::openStateConfig() sounds like a good idea to me.

Your code example would create ~/.local/share/app/apprc. I wonder whether we should name that something like appstaterc instead to avoid confusion with ~/.config/apprc

I'm working on a replacement for KRecentFileAction to be introduced in KWidgetAddons

Update on the config vs state thing: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/4 https://invent.kde.org/frameworks/kconfig/-/merge_requests/33

Can we make sure KActivitiesStats or whatever recent docs thing is aware of the new location used y KRecentFileMenu. I believe @meven worked in that area (e.g. for GTK file dialog feeding into that, too).

KIO currently has KRecentDocuments as well, just to add confusion to the mix. I certainly wish it would disappear or move down in tierness, it's not KIO related.

Obviously telling kactivitiesstats shouldn't be done via DBus, from KWidgetAddons. So either KActivitiesStats can do file watching, or we need a higher level class/method on top.....

either KActivitiesStats can do file watching

That's what it does for KRecentDocuments, yeah, in [1].

[1] https://invent.kde.org/plasma/kactivitymanagerd/-/blob/master/src/service/plugins/eventspy/EventSpy.cpp#L27

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

Or maybe I'm mixing up the per-app list of files, and the Plasma-global recent documents. But it sounds like the former should feed the latter.

Created a separate task for KRecentDocuments: T14236

Can we make sure KActivitiesStats or whatever recent docs thing is aware of the new location used y KRecentFileMenu

I don't think anything needs to be done. KActivitiesStats watches KRecentDocument::recentDocumentDirectory() (.local/share/RecentDocuments) which is different to the location read by KRecentFilesAction (usually somewhere in the apprc file)

Assuming that QMenu will go to QtQui, which is planned

Looks like QMenu is still in QtWidgets, which throws a wrench in the plan to move KRecentFileMenu and KStandardActions to KGuiAddons

KRecentFileMenu exists so the tier issue is "solved".

KRecentFileAction still needs to be ported away from, but that's a somewhat separate issue: T16706