Using current git 2c04b1a When entering something into the Find bar (ctrl-f), the content is highlighted in green if found in the document, or red otherwise. KDevelop always uses the same highlighting colours as in Breeze, regardless of the theme, but uses the theme text colour. This causes the text to be unreadable when using dark themes. This does *not* happen in KWrite or Kate, despite apparently using the same ktexteditor code. I haven't found out why.
Can confirm. This makes either dark themes or find feature very cumbersome to use.
Please debug this, I won't have the time to do it.
I've tried a few times It does follow the desktop theme, but ignores KDevelop's custom colours (which if used are typically opposite to the desktop, so it's quite obvious). The immediate cause is KColorScheme reading colours directly from the config, which hasn't been updated with the custom colours, rather than the application palette. Not entirely sure whether it's KConfigWidgets being buggy or if we're using it wrong somehow.
So, passing `KSharedConfig::openConfig(qApp->property("KDE_COLOR_SCHEME_PATH").toString()` into all the KColorScheme::foo() calls makes this work. There are actually less-obvious effects from other uses of KColorScheme, e.g. in the CMake status text colour. I'm pretty sure this should be handled in KColorScheme - after all, the property is set by KColorSchemeManager, and KTextEditor shouldn't need to care whether a parent application is using that. [moving bug]
*** Bug 373093 has been marked as a duplicate of this bug. ***
Git commit a3355b22954b61f7e9b9077d9663ffc592b9eb4b by Francis Herne. Committed on 19/02/2017 at 20:01. Pushed by flherne into branch 'master'. KColorScheme: default to application scheme if set by KColorSchemeManager KColorSchemeManager::activateScheme() sets a custom path for the application's color scheme, with `qApp->setProperty("KDE_COLOR_SCHEME_PATH", index.data(Qt::UserRole));` Currently, the KColorScheme() and KStatefulBrush() constructors will ignore this and use only the system color scheme, unless an application-specific config is explicitly loaded and passed in by the caller. This is problematic, because most callers assume that the default is to match the *application* scheme - usually this is equivalent, but it differs when KColorSchemeManager is used. For example, when the application of a KTextEditor widget or KonsolePart has an opposite color scheme to the system, the Find bars are unreadable. This patch makes KColorScheme() match the application scheme by default when this differs from the system scheme, which seems preferable to adding the same code in hundreds of callers. Differential Revision: https://phabricator.kde.org/D4637 M +10 -3 src/kcolorscheme.cpp M +16 -14 src/kcolorscheme.h https://commits.kde.org/kconfigwidgets/a3355b22954b61f7e9b9077d9663ffc592b9eb4b