Bug 373764

Summary:	`KColorScheme::adjustBackground` and other methods ignore effects of `KColorSchemeManager::activateScheme`
Product:	[Frameworks and Libraries] frameworks-kconfigwidgets	Reporter:	Francis Herne <mail>
Component:	general	Assignee:	kdelibs bugs <kdelibs-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kde, kfunk, urmet.saar
Priority:	NOR
Version First Reported In:	5.29.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://commits.kde.org/kconfigwidgets/a3355b22954b61f7e9b9077d9663ffc592b9eb4b	Version Fixed/Implemented In:	5.32.0
Sentry Crash Report:

Description Francis Herne 2016-12-17 14:14:56 UTC

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.

Comment 1 Urmet Saar 2017-02-03 13:14:09 UTC

Can confirm. This makes either dark themes or find feature very cumbersome to use.

Comment 2 Kevin Funk 2017-02-14 09:30:40 UTC

Please debug this, I won't have the time to do it.

Comment 3 Francis Herne 2017-02-14 09:37:01 UTC

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.

Comment 4 Francis Herne 2017-02-14 14:48:20 UTC

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]

Comment 5 Sven Brauch 2017-02-19 15:37:37 UTC

*** Bug 373093 has been marked as a duplicate of this bug. ***

Comment 6 Francis Herne 2017-02-19 20:18:54 UTC

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