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