Make kconf_update more robust
Open, Needs TriagePublic

Description

We have kconf_update which runs on login(?) or when opening the config(?) for updating configuration after updates.
However, this falls flat on its face when the process is already running, e.g. in case of kglobalaccel or spectacle, where the process will just write down its own outdated config again.

We need something better than what we currently have.

broulik created this task.Jan 13 2020, 9:33 AM

Yes please!

I've hit issues with kconf_update so many times.
Plus it's fundamentally incompatible with snaps/flatpaks/appimage where it'll install the update script into a different place to where kded is reading them.

I'm not sure if we want to change kconf_update or simply introduce something new alongside.
The latter doesn't need KF6, if anything it's better to have a chance to change the API after we make it.

IMHO what would be best in practice is the relevant program adding early in their main:

addConfUpdate(QString configName, int version, std::function someCallback);

This updates some static map, which KConfig::KConfig checks whenever it finishes opening the relevant config file, calling the callback if the version in the config is too old (in some thread-safe way obviously).
Bam! no need to write a random script with a made up syntax, it'll process things at the right time, and it allows for any code.