GitLab

Andreas Haratzis authored Oct 04, 2020 and Nate Graham committed Oct 12, 2020

Fix for occasional background glitches behind transparent Menus, especially when hovering over menu elements.

Bug: 399680

Issue:
Breeze sets the WA_TranslucentBackground attribute on Menu widgets to achieve transparency.
This implies WA_NoSystemBackground, which makes Qt not repaint the background when content changes.
This is fine for things like tooltips which don't change content, but for dynamic content (like hovering over menus), Breeze ends up painting over the previous frame.

Fix:
We render menu panels with CompositionMode_Source to ensure the previous frame is obliterated.
We could reset the buffer by painting transparent pixels first, but that is wasteful.

Notes:
I have ensured that overlapping transparent menus still appear OK (they are rendered over each other with the compositor).
On Wayland, occasionally colours appear behind the rounded borders. I believe this is a kwin issue because it doesn't occur in X11.


(cherry picked from commit 01f0c885)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

GIT_SILENT

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Currently the condition in the #if directive evaluates to false (sorry
for breaking it!).

In order to prevent breaking Helper::isX11() in the future, this change
removes the #if directive. It's okay to do so because KWindowSystem
provides a platform-independent API.


(cherry picked from commit 9b59cfc3)

Seperate sunken and checked state. Use HighlightedText when the arrow is hovered
because it will a hover color tinted background.


(cherry picked from commit c61a78b0)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Janet Blackquill authored Sep 21, 2020 and Nate Graham committed Sep 21, 2020

BUG: 426651


(cherry picked from commit 659e3d35)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

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 5f62d1c7)

QWindow::startSystemMove, which was introduced with Qt 5.15, was added
with commit 6d83b045.

GIT_SILENT

QWindow::startSystemMove() is a new feature in Qt 5.15 that provides a
platform-independent way to start an interactive move operation.

GIT_SILENT

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Not useful for buttons themselves but for widgets/items that are based on buttons
such as KeySequenceItem.

I was in a video call with Volker and asked him under which license the GtkUpdateIconCache
is licensed.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

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.

This changes ToolButtons to behave similar to PushButtons, so they both
draw an downward pointing arrow when they have a menu.

BUG: 344746

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.

use global animation values for duration: as the widget style has the
same, the animations wikll be together