As we have discussed, this mechanism is considered Plasma-internal, meaning
that we don't have to keep the KServiceTypeTrader stuff around.
To avoid duplicating the KCMs or having to split the kcminit stuff in a separate
binary, symlinks are used to query the available plugins. By having a unified "kcminit"
symbol for the function which will get called, we can drop the need for the
custom property.
Task: https://phabricator.kde.org/T14335
Prequisite for using only embedded json metadata for the KCMs, see https://phabricator.kde.org/T14517
Add explicit find_package() and #include's that are required and were
pulled in by KDELibs4Support.
krdb: remove one redundant #include, KColorUtils
kcm_fonts: send dbus message directly to org.kde.KDEPlatformTheme to
'refreshFonts'
kcm_style:
- use KToolBar::emitToolbarStyleChanged() to notify of toolbar style changes
For the rest use the notifyKcmChange() private method to send the dbus
signal.
[1] https://invent.kde.org/frameworks/kdelibs4support/-/blob/master/src/kdeui/kglobalsettings.cpp#L860
This matches the install location scheme QT_PLUGIN_DIR/kcms/, which makes
it slightly easier to test stuff right from the builddir, without
installation, by exporting QT_PLUGIN_DIR=builddir/bin/.
Also install kcm_fontinst in QT_PLUGIN_DIR/kcms/, like the other KCMs.
Making it a library instead of including the source from multiple places
has several advantages. We get proper dependency and include path
propagation. We can specify the krdb dependencies once instead of
repeating them for each kcm. This allows for a better separation between
the KCM's actual dependencies and krdb's dependencies.
We currently need the lookandfeel and style kcm in plasma-workspace, but
appearantly they depend on the krdb so best solution is to move all kcms
together
They are taken from plasma-desktop at the commit :
8447c08e878ccbde9c5516ba8a912993ea199cb9