I'm missing what is non-trivial about the kdeinit tie-in.

The current code starts runs phase 0, forks, startup continues then a DBus call is made to phase 1.
We can keep that and still stop the kdeinit usage in the code.

Of course (and I only know because it was exactly like that at some point, before I removed the phases-related code too in the same change, which in hindsight was a bit stupid :), I could have at least kept it as a separate commit in the same MR).

Adding to the list of things to discuss, the usefulness of the phases in kcminit:
I grep'ed for 'X-KDE-Init' almost everywhere in KDE repos and I only found:
X-KDE-Init-Phase=0:
plasma-workspace/kcms/style/kcm_style.desktop:8:X-KDE-Init-Symbol=kcminit_style
plasma-desktop/kcms/input/mouse.desktop:8:X-KDE-Init-Symbol=mouse

X-KDE-Init-Phase=1:
plasma-desktop/kcms/touchpad/kcm/kcm_touchpad.desktop:8:X-KDE-Init-Symbol=touchpad
kgamma5/kcmkgamma/kgamma.desktop:213:X-KDE-Init-Symbol=kgamma

No phase? :
plasma-desktop/kcms/keyboard/kcm_keyboard.desktop:9:X-KDE-Init-Symbol=keyboard

I don't think the phase split makes sense, a) because it's not used by many modules anyway, and b) it doesn't make sense to keep it for the same reasons is being deprecated/removed (hardware, specially storage, i.e. SSD, has become a lot faster).

So kcminit should be launched as one process, (oneshot in systemd service).

How is this tied to kinit at all? As far as I can see a QFunctionPointer is read from the lib and that function is then executed.

@alex it isn't.

I don't think the phase split makes sense,

Ack, I'm happy to drop that.

I think in general the concept of kcminit makes some sort of sense. It allows us to drop specialisations in startplasma, and that's a good thing.

In T14335#261955, @davidedmundson wrote:

I don't think the phase split makes sense,

Ack, I'm happy to drop that.

I think in general the concept of kcminit makes some sort of sense. It allows us to drop specialisations in startplasma, and that's a good thing.

I think (hope) I kept that commit somewhere on my disk :)

In general I am wondering if it is a good thing to keep loading this function pointer from the KCMs.

It basically means that we would have to load all the available KCMs and check if the metadata says that they have a init function. Especially if we get rid of KServiceTypeTrader this will become more of a problem. Introducing a namespace like plasma/kcms/systemsettings/kinit could be possible, but TBH that is rather ugly.

Could we be better off just loading those using KPluginLoader from a specific namespace? Then it would not be about KCMs, but rather loading a small init function in startplasma.

There were some choices discussed at the KF6 weekly:

• Install desktop files into specific dir like plasma/kcminit and then query metainfo from there => bad because we would have to open two files and the init phase stuff can be removed. Also the X-KDE-Init-Symbol could be a standardized value.
• The namespace solution as above would work, but as said it is ugly to make systemsettings depend on the kcminit specific stuff
• Just loading them as plugins => the functions are linked to the KCMs because there they are also called on-save. Having a small static lib would work though

Another solution would be to create a dir called plasma/kcminit and synlink the KCMs there. Then we have to resolve an extra symlink at plasma startup but that should not cause too big issues performance wise. Similar to the kinfocenter symlink logic.

Can the kcminit stuff be considered plasma-internal API?

I think so

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1201
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/692
https://invent.kde.org/plasma/kgamma5/-/merge_requests/5