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.
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
We would like to destroy a shadow after the decorated window has gotten
unmapped or destroyed. To do that, we install an event filter on the widget
and make the shadow a child of the underlying window.
Unfortunately, the underlying window and the widget have different life
times. To counter for that, we clean up _shadows after the shadow has
been destroyed. This turned out to be a bad idea because when someone
does qDeleteAll(_shadows), QMap iterators will become invalid.
Since KWindowShadow handles the case where it becomes orphaned gracefully,
we can make shadows children of widgets to work around the crash.
Still, it would be nice to call KWindowShadow::destroy() after the native
resources for the window have been destroyed.
Summary:
The look of Breeze menu titles has always slightly bothered me since they have the same
visual style and weighting as items, so they look clickable even though they aren't, and
they don't really do a very good job of separating sections, as seems to be their purpose.
This patch my my attempt to remedy the situation by making them look more "title-like"
and have greater visual distinctiveness from the items above and below them.
Test Plan:
Plasma Task Manager item context menu, before: {F8252758}
Plasma Task Manager context menu, after: {F8253825}
KMoreTools menu, before: {F8252757}
KMoreTools menu, after: {F8253827}
Reviewers: #vdg, #breeze, niccolove, ndavis
Reviewed By: #vdg, #breeze, niccolove, ndavis
Subscribers: cblack, cfeck, ndavis, niccolove, broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D29081
Summary: When hovering a focused combobox the icon was in Selected state resulting in a wrong color.
Test Plan: Hover over a focused combobox that has an icon
Reviewers: broulik, #breeze, ndavis
Reviewed By: #breeze, ndavis
Subscribers: ndavis, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28908
Summary:
Caused icons to be not longer recolored when changing the color scheme until an
application is started again
Test Plan: Change color scheme while having an application open, icons should change color correctly
Reviewers: #breeze, #plasma, ndavis
Reviewed By: #breeze, ndavis
Subscribers: ndavis, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D29012
Summary: Caused some icons not be colored correctly
Test Plan: Close KWrite with unsaved changes, all icons should be colored correctly
Reviewers: broulik, ngraham
Reviewed By: broulik, ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28830
Summary:
Our icons can be recolored. However there is a difference between custom colors
on widgets and icons. We will respect the palette but KIconLoader that creates
the icon pixmaps operates on an application wide palette basis. This can create
miscolored icons when a widget has a custom palette. A helper function is
introduced to load the pixmaps that switches the palette of the global
KIconLoader if necessary and resets it appropriately.
Test Plan:
Before:
{F8205856}
After:
{F8205857}
Reviewers: #breeze, ndavis, cblack, hpereiradacosta, mart
Reviewed By: cblack, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28433
Summary:
After a widget has been unregistered, a WinIdChange event may be sent.
If that happens, ShadowHelper is going to try to install a shadow for
the corresponding widget. Obviously, this is wrong.
Reviewers: #plasma, cblack
Reviewed By: cblack
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28075
Summary:
Every time Breeze needs to check whether given widget has an alpha
channel, it makes a synchronous X call to figure out whether a
compositing window manager is running on a particular screen. This
is inefficient!
Luckily for us, Qt XCB QPA monitors compositing manager selections
and caches the ownership status of each one. That cached ownership
data can be accessed via QX11Info::isCompositingManagerRunning().
Reviewers: #plasma, hpereiradacosta
Reviewed By: hpereiradacosta
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26978
Summary:
Since Qt 4 style plugin had been dropped, we can use QX11Info::connection()
directly.
Reviewers: hpereiradacosta
Reviewed By: hpereiradacosta
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D27000
Summary:
Since lifetime of a KWindowShadow doesn't strictly match the lifetime
of the associated widget, we need to unregister the shadow when it's
destroyed in order to prevent accessing or deleting dangling pointers
afterwards.
BUG: 416854
Test Plan: plasmashell no longer crashes.
Reviewers: #plasma, broulik
Subscribers: apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26966
Summary:
The primary task of a compositor is to take a bunch of buffers from
different clients and present them on the screen. However, the compositor
may need to present its own stuff on the screen as well.
On X11, internal clients (the ones created by KWin) are backed by real
windows. This looks a bit clumsy since KWin uses X11 to communicate with
itself.
On Wayland, we use our own QPA that talks to KWin directly. Given that
internal clients with the custom QPA are no longer backed by wayland
surfaces or x11 windows, things like blur, background contrast, and
shadows must be set through KWindowSystem APIs so KWin can catch the
relevant API calls and handle them accordingly.
The good thing is that we get rid of a good portion of platform-specific
code. The bad thing is that we still need to be cautious about QPAs that
destroy the underlying platform resources upon a window becoming hidden.
Reviewers: #kwin, #plasma, mart
Reviewed By: #plasma, mart
Subscribers: mart, plasma-devel
Tags: #plasma
Maniphest Tasks: T12496
Differential Revision: https://phabricator.kde.org/D26475
Summary:
KWindowSystem cannot be used in the Qt 4 style plugin. On the other hand,
we need to use KWindowSystem to make QWidget-based internal clients in
KWin cast drop-shadows.
Another problem with the Qt 4 style plugin is that some distributions
have already dropped Qt 4, so one has to build it first in order to
verify that his or her change works with Qt 4.
Given maintenance burden and the fact that Qt 6 is around the corner,
this change drops the Qt 4 style plugin.
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: davidedmundson, mart, plasma-devel
Tags: #plasma
Maniphest Tasks: T12496
Differential Revision: https://phabricator.kde.org/D26476
Summary:
center only the drawing of the components but never modify the
subcontrolrects (and hit targets)
BUG: 416348
FIXED-IN: 5.18.0
Test Plan:
now the handle activates immediately without one single pixel
margin
Reviewers: #vdg, hpereiradacosta, ndavis
Reviewed By: #vdg, ndavis
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26783
Summary:
center only the drawing of the components but never modify the
subcontrolrects (and hit targets)
BUG: 416348
FIXED-IN: 5.18.0
Test Plan:
now the handle activates immediately without one single pixel
margin
Reviewers: #vdg, hpereiradacosta, ndavis
Reviewed By: #vdg, ndavis
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26783
Summary:
This look makes listviews look way better, not having the selected
items look truncated into nothingness.
Always display "big" handles, due to the numerous complaints of the slim handles not being obvious
Test Plan:
Before:
{F7882628}
After:
{F7882624}
Reviewers: #plasma, #breeze, #vdg, ngraham, hpereiradacosta
Reviewed By: #vdg, ngraham, hpereiradacosta
Subscribers: ndavis, ahiemstra, hpereiradacosta, mthw, plasma-devel
Tags: #plasma
Maniphest Tasks: T9126
Differential Revision: https://phabricator.kde.org/D26655
Vlad Zahorodnii
Carson Black
David Redondo
Heiko Becker
l10n daemon script
Nate Graham
Lucas Andrade
Arjen Hiemstra
Cyril Rossi
Martin T. H. Sandsmark
Noah Davis
Kai Uwe Broulik
David Edmundson
Vlad Zahorodnii
Marco Martin