Currently we are very inconsistent with how we handle our various X11 dependencies.
Some places check whether specific sub-libraries are found and disable parts of the code accordingly.
Sometimes this is controlled by whether X11 is found at all, sometimes it depends on the sublibrary being present.
Some of this is obviously broken, e.g. in one like we check whether X11 is there and then use it unconditionally a few lines down.
Instead of the current system of optional deps and deps being conditional on other deps I propose that we introduce an explicit build option that controls the X11 support.
If on (the default) then all X11 libs are required.
If off then no X11 libs are searched for. Currently this results in a broken build since some places use X11 stuff unconditionally, but it gives us an easier way to test and fix those cases.
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
StartPlasma's fontDPI syncs the current font DPI to xrdb, which affects
font DPI for X applications (inc apps run in xwayland)
This is seldom used on wayland as with framebuffer scaling you don't
want to adjust your font DPI, but it is used by some users. As it's
xrdb, it needs to come after Xwayland is started for the wayland case.
The goal of this patch is to move towards killing the
startplasma-waylandsession binary as well as just being better design to
have these things comparmentalised.
kcminit is very early in the boot process before all GUI apps with the
exception of ksplash. I don't think this will make a big difference as
that's just a picture anyway?
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
Nicolas Fella
Alexander Lohnau
Volker Krause
David Edmundson
Benjamin Port
Ahmad Samir
Bhushan Shah