D20205: initialize the kcolorscheme at the first app start
Marco Martin
noreply at phabricator.kde.org
Wed Apr 3 09:20:24 BST 2019
mart added a comment.
In D20205#442466 <https://phabricator.kde.org/D20205#442466>, @davidedmundson wrote:
> The analysis makes sense, I don't understand why this is the correct fix.
>
> Colours aren't the only thing lookandfeel syncs to kdeglobals when set.
> Is it correct that all of them have a fallback to loading a second config? If they do, why does the lnf kcm copy into kdeglobals instead of just deleting the kdeglobals entries?
as far i know, kcolorscheme only looks for colors in kdeglobals (more precisely, reads from KSharedConfig::openConfig(), which is from applicationnamerc and then falls back to kdeglobals)
an alternative approach could also be making kcolorscheme directly read from lnf, tough, may add complexity is a more often used code path?
the fallback is:
- colors in applicationnamerc
- colors in kdeglobals
- colors from the colorscheme file set as ColorScheme again in kdeglobals
- look in the lnf package set in kdeglobals, then look if it contains a "colors" file
- look in the lnf package set in kdeglobals, then look at the "defaults" file in the lnf, and look at the color scheme name
Is probably better to do this dance only once at startup?
REPOSITORY
R135 Integration for Qt applications in Plasma
REVISION DETAIL
https://phabricator.kde.org/D20205
To: mart, #plasma
Cc: hein, davidedmundson, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20190403/1bc9c56a/attachment.html>
More information about the Plasma-devel
mailing list