kossebau added a comment.
I am even more confused that switching back to "Breeze" from "Breeze Dark", I can still reproduce things when just switching to dark color themes only. So possibly that is enough, and I was before potentially fooled by some running processes, despite making sure no thumbnailer kio-slave was idling, or by some improperly propagated UI color palette changes). So possibly indeed just the UI color palette effective here, Plasma unrelated. Re: Kate: seems from its text document UI schemas "Normal", "Printing", "KDE", "Breeze Dark", "Solarized (light)", Solarized (dark", "Vim (dark)". the "KDE" one is the one which adapts to current workspace UI color theme, while the others all have a completely hard-coded palette? @vkrause Given the API dox claiming that enum KSyntaxHighlighting::Repository::DefaultTheme lists "Built-in default theme types", to me it comes a bit of a surprise that the theme actually adapts to the UI color theme, as this is not documented. E.g. if one uses this for printing on paper, getting different results depending on current UI color theme would result in a bit randomness. Perhaps there should be additional option(s) for default theme(s) which adapt to the UI theme. Though this also needs support for adapting in case the user changes the theme (e.g. think of discussion about day & night modes using different color themes). So: IMHO the default themes should be hard-coded. And support for highlighting themes adapting to the currently active UI color palette should be officially added and documented. REVISION DETAIL https://phabricator.kde.org/D20766 To: eshalygin, kossebau, cfeck Cc: dhaumann, cullmann, vkrause, cfeck, meven, broulik, kde-frameworks-devel, kfm-devel, alexde, feverfew, michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, mikesomov
