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
We've gotten some feedback that radio buttons look like big creepy eyes
that are staring at you. To reduce that effect, this commit makes the
center dots a bit smaller.
Controls that only reveal on hover are extremely user-aggressive,
especially when part of their job is to indicate the current status
of a view ('can I scroll any further?').
Always-visible arrows have a large set of usability benefits:
- the user always knows where they are on screen and can
move their pointer to interact with them without having
to first move to the scrollbar, then to the arrows, or
memorise the positioning of the arrows.
- they always perform their job of indicating whether or not
the user is at the end of a scroll view.
That point is especially important because the current
status quo means that a user can't quickly tell if a scrollbar
is at the end of its track without hovering over it, due to
the gap created by invisible arrows.
Users enabling scrollbar arrows are also likely to prefer a
more utilitarian than a more 'sleek' UI, so this caters to them
better.
It doesn't make much sense to keep the raw pointer of a weak pointer
that could potentially disappear at any point.
This fixes warnings and just uses references like they're meant to be
used.
Nate Graham
l10n daemon script
Alexander Lohnau
Kai Uwe Broulik
Noah Davis
Jan Blackquill
Jonathan Riddell
Niccolò Venerandi
Ismael Asensio
David Edmundson
Nyan Pasu
Nicolas Fella
Aleix Pol