The previous way it was painted was kind of messy in the sense that
other parts overlapped with the active tab when they shouldn't have or
didn't overlap enough like with the highlight. There were also some
painting artifacts that were just weird and are now gone.
This is no longer the default color scheme; Breeze Light is. But being
named "Breeze" implies that is is the default or at least the base,
rather than simply one of several variants. Let's rename it to "Breeze
Classic" to make it follow the pattern and avoid subtly giving it more
textual weight.
This color scheme is a misnomer, and does not actually offer higher
contrast than other color schemes. In fact its contrast is generally
worse. As a result it hurts more than it helps. A true "high contrast
mode" would require changes to the QStyle to make UI elements larger or
change their borders to actually offer an improvement for people who
need higher contrast than what is offered by Breeze and Breeze Dark.
Accordingly, let's delete this color scheme and migrate current users to
Breeze Dark, which is the shipped theme that looks closest to it, and
has *better* contrast in many ways.
BUG: 352506
BUG: 442286
FIXED-IN: 5.24
These colors were previously using the same values as in other contexts,
but this was not appropriate for the Selection set, because contrast and
readability were low. This commit addresses that by making the colors
darker just for the Selection color set. Now they are much more
readable.
This change is made to all four of the Breeze* color schemes, as they
all suffered from the issue.
BUG: 406239
FIXED-IN: 5.23
This option is off by default and has been for several years, after it
was briefly turned on by default and proved to be unpopular with users,
generating many complaints and bug reports. The line uses a semantically
inappropriate highlight color which is far too visually bright, and it
doesn't look good with any of our header-color-using color schemes.
Arguably it never looked good with older color schemes where the titlebar
and window background use different colors either. Let's remove this
option.
BUG: 427422
FIXED-IN: 5.24
A style shouldn't mess with clients like this, especially
if it behaves different from literally any other QStyle out
there, and breaks decades of muscle memory.
This partially reverts 00693ee5e7
BUG: 438994
- Use a very slight gradient
- Use blue for pressed state
- Make shadow vertical, not diagonal
- Use gray for checked buttons
Some people thought blue checked buttons were pretty, but some people
thought they demanded too much attention. In order to merge the changes
faster, I switched to using gray for checked buttons.
This reverts commit c8a5b48ac1.
This commit was mostly added because its author (me) wanted another person to "shut up"
in regards to their strong opinion about the appearance of a UI element they seldom use,
and not because they thought it was an improvement to the UI element or that it made the
UI element more consistent with others.
That was a mistake.
The commit introduces huge contrast issues w/ menubar items, where it's hard to tell that
they're being hovered or are currently opened, especially in sunlight.
This goes back to the prior status quo, where the menubar's state is easily read in all
environments.
This is an off-by-default option of the breeze style which, when
turned on, changes the background role of `KTitleWidgets`. The
result looks mostly like a color bug.
It also removes the need for a special workaround.
This fixes hover colours in qqc2-desktop-style, which
has no widget for us to poke at, so we have to use
activeSubControls instead, which we do have, regardless
of whether or not there's a widget.
BUG: 434884
Previously, in Qt Widgets with the Breeze theme active,
QAbstractSpinBox::setButtonSymbols(QAbstractSpinBox::NoButtons) would
hide the buttons but leave a white space where the buttons would
normally be. This changes the Breeze theme to skip adding the width of
the hidden buttons to the spinbox's width.
BUG: 440718
FIXED-IN: 5.23