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
If the style is unloaded for example by an application dynamically
switching styles, the listener was still around leading us to call
into destroyed objects when the color scheme was changed.
BUG:432660
Same concept as 03fb4b4900. Not worth the attempt; most dialogs don't draw edge to edge, and the ones that do most likely don't work well with the top border.
l10n daemon script
Niccolò Venerandi
Fabian Vogt
Jonathan Riddell
Vlad Zahorodnii
Jan Blackquill
Paul McAuley
Alexander Lohnau
Kabir Akzaman
Nicolas Fella
Nate Graham
Marco Martin
David Redondo
Laurent Montel
Anthony Fieroni