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
Jan Blackquill
Ismael Asensio
David Edmundson
Nyan Pasu
Nicolas Fella
l10n daemon script
Aleix Pol