ManagedConfigModule::save() writes the value for the 'ColorScheme' entry to disk.
If we notify the settings change anyone who connects to it may read the old value before the new one is saved.
To avoid this race consition emit the signal after saving instead of before
Instead listen to KNS signals and only update the parts that are needed.
The signals from the qtquickengine also produce less unwanted noise
because the signal does not get emitted for intermediate states.
This also prevents the scrolling position from scrolling unnecessarily
to the top.
Store as kdedefault only the colorscheme, colors data can still live in kdeglobals
They are not used to change default.
This will simplify code and fix some bugs when we apply theme without all groups
This commit changes what counts as the default settings to take into account the default
settings of the current Global Theme.
e.g. if you change the Global Theme to Breeze Dark, when you go to the color KCM, clicking
the "Defaults" button will revert to the Breeze Dark color scheme (because it is the default
color scheme of the active Global Theme), rather than Breeze Light.
Since these KCMs can display user and distro provided content, we can't
ensure that everything will begin with a capital letter. Accordingly, we
should sort the grid case-insensitively to prevent the entries starting
with lowercase letters from being shunted to the end.
CCBUG: 404608
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