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
We can get the metadata form the C++ plugin and set that for the kpackage.
This way the files are not duplicated in source, on disk and in memory.
Task: https://phabricator.kde.org/T14983
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
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
Nicolas Fella
Alexander Lohnau
Ahmad Samir
Kai Uwe Broulik
Laurent Montel
Bhushan Shah