The order in which the underlying window and the shadow are destroyed is
undefined. In most cases, the shadow is destroyed after the window, but
in rare cases it may be vice versa, for example it's the case with popup
menus in Dolphin. If the shadow is destroyed before the window, then
the window will be shadowless when the compositor animates it.
The only way to guarantee that the shadow is destroyed after the window
is to create a parent-child relationship between two.
Given that the widget and the window have different lifetimes, we have
to be extra careful with keeping dangling pointers out of _shadows.
(cherry picked from commit 5f62d1c74e)
The direction of the sort order indicator arrows has historically been
controversial:
1. Camp A asserts that the arrow should reflect the currently applicable
word: "ascending" or "descending". For example Ascending order should
be represented by the arrow pointing up. It's ascending, get it?
2. Camp B asserts than the arrow should reflect the visible order of
items in the view. For example when the biggest things are on top,
the arrow should be pointing down; it's showing you the direction of
the visible items: big to small.
3. Camp A then correctly points out that if Camp B gets their way, the
arrow no longer matches the word displayed in the UI ("ascending"
or "descending).
However over the years we have accidentally solved this dilemma! We all
pretty much agree that the terms "ascending" and "descending" are
confusing to users, and we have replaced them with human-readable
descriptions such as "A-Z" and "Largest first". As a result, the arrows
are no longer consistent with the words "ascending" or "descending"
because we no longer show those words in the UI anymore. So the only
remaining thing for the arrow to be consistent with is the set of items
displayed immediately below it. For this purpose, reversing the default
order per Camp B is more appropriate because then the arrow points in
the direction of the sorting: biggest on top gets a downward-pointing
arrow, and smallest on top gets an upward-pointing arrow.
There is a hidden option in Breeze that does just that; this patch flips
it from false to true to effect the above change.
The only difference between the new instant-popup buttons and these when
flat is the color of the arrow, which is not a very good indicator. So
on hover, also draw the separator between the menu button and the main
button for these toolbuttons on hover or when it has focus, which makes
things a little clearer.
Task related : Figure out a good UI for the "show which settings have been changed" feature https://phabricator.kde.org/T13008
This patch introduces a new property to allow to highlight some widgets when we want to draw user's attention on specific widgets.
Summary:
In addition to the specific Breeze animation settings, KDE has "global" animation settings primarily used for `Qt::UIEffect`s like `Qt::UI_AnimateMenu`, `Qt::UI_AnimateCombo`, `Qt::UI_AnimateTooltip` and `Qt::UI_AnimateToolBox`.
This patch ensures that Breeze use and respect those settings, which both harmonizes with other styles (if `QGuiApplication::desktopSettingsAware()` is true).
Test Plan:
Turn animations on and off in kdeglobals, and see animations turn off and on when using Breeze.
Also makes https://phabricator.kde.org/D17732 work properly with breeze.
Reviewers: #breeze, ngraham
Reviewed By: #breeze, ngraham
Subscribers: meven, cblack, davidedmundson, ngraham, hpereiradacosta, ndavis, plasma-devel, #breeze
Tags: #plasma, #breeze
Differential Revision: https://phabricator.kde.org/D28651
Carson Black
l10n daemon script
Lindsay Roberts
Bhushan Shah
Vlad Zahorodnii
Heiko Becker
Nate Graham
Laurent Montel
Niccolò Venerandi
David Redondo
Lucas Andrade
Arjen Hiemstra
Cyril Rossi
Marco Martin
Martin T. H. Sandsmark
Noah Davis
Mikhail Zolotukhin