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.
While the SplitterProxy is active, it intercepts all relevant events, so that
the underlying widget still thinks it's in the same "on splitter" state. When
the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
event to make it aware of the new current cursor position. Without this, it
doesn't know that it's not supposed to be in the "on splitter" state, and when
it regains focus it just re-activates the SplitterProxy at the current cursor
position.
This was broken by accident in d201a1f187 ("Fix SplitterProxy not clearing
when above another QSplitterHandle"), which moved the hide() call past the
call to QCoreApplication::sendEvent. Previously that made isVisible() false,
which also prevented the interception of the HoverLeave/HoverMove events.
BUG: 436473
The shadow protocol lacks relevant requests to specify the device pixel
ratio. In addition to that, the difference between scaled shadows and
hidpi shadows is very subtle, so it's not worth spending more computing
resources.
When two SplitterHandles are next to each other, like at the intersection of a
horizontal and vertical splitter (|-), then it's possible that hiding the proxy
of one of those handles causes the other handle to gain focus immediately,
which activates the SplitterProxy again. Before this patch, it would then
continue clearing after reenabling itself, leading to an inconsistent state.
BUG: 431921
It clears the splitter when enabling it, that seems wrong.
Despite this bug, it still mostly worked before because the eventFilter checked
for _enabled anyway.
This reverts commit 2f351fe101.
We hve not yet figured out how to apply this style consistently
and were unable to implement it for controls other than text fields
in Plasma 5.21, so it is better to remove it for now than to have an
inconsistent UI. We will re-evaluate this for Plasma 5.22.
BUG: 430944
BUG: 430943
BUG: 433421
FIXED-IN: 5.21.2
Make again the root item accept mouse clicks, so the qwidget
part won't take over. also ungrab the mouse of the QQuickItem
as soon as the system move start, so won't eat the first click
after the system move has been performed. Being a QQuickItem
that accepts the mouse press, Input Handlers know how to steal
the event from it even if they don't accept it.
This reverts commit 6919b948ca.
BUG: 433178
FIXED-IN: 5.21.2
This reverts commit ef234aca49.
CCMAIL: uhhadd@gmail.com
CCMAIL: kde@david-redondo.de
This commit was inappropriately reverted with no discussion for the
second time, ignoring the comment recommending against it in
https://invent.kde.org/plasma/breeze/-/merge_requests/82#note_190308.
This is a community project and you are not the maintainer. Please do
not revert this again, and also stop reverting changes you disapprove
of without discussion. This is an inappropruate use of your commit
rights and may result in their revocation if you keep doing it.
Further offenses will be reported to the CWG.
This reverts commit 9f40b17e57.
The idea of a Tools Area separator only makes sense when there is a unibody
Tools Area. When using a color scheme without Header colors, there is no
Tools Area (just a disparate collection of titlebars, manubars, and
toolbars), so the line is just extra visual noise that various people
have objected to following the Plasma 5.21 release. Let's make it
conditional on using a color scheme with Header colors again.
BUG: 433118
FIXED-IN: 5.21.1
Noah Davis
Jan Blackquill
Ismael Asensio
Nyan Pasu
Nicolas Fella
Nate Graham
l10n daemon script
Fabian Vogt
Vlad Zahorodnii
Alexander Lohnau
Marco Martin