https://bugs.kde.org/show_bug.cgi?id=373764
Francis Herne <m...@flherne.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit| |https://commits.kde.org/kco
| |nfigwidgets/a3355b22954b61f
| |7e9b9077d9663ffc592b9eb4b
Status|CONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Francis Herne <m...@flherne.uk> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
