THe previous color was too difficult for me to distinguish between
active and inactive windows. This slight darkening of the active
state improves the legibility while still preserving the "light"
quality of the style.
Breeze Twilight is a variant of Breeze Default that opts for the dark
variant of the Plasma Style instead.
With Kubuntu having taken this approach, and with Fedora now considering
this approach as well, it's time we consider doing it upstream, because
honestly Breeze Light for Applications + Breeze Dark for Desktop is a
really nice looking combination.
Effectively do the same as in the past when we do not have a headers group.
Trigger for this is that the line does not work in such cases but we also
do not need to draw the background in any special way then.
The current options are quite bad and result in files which are unnessarily
big, even bigger than the original file. The Pillow documentation says:
> Values above 95 should be avoided; 100 disables portions of the JPEG
> compression algorithm, and results in large files with hardly any gain
> in image quality.
"100" is not a valid value for the subsamping parameter either.
This change actually enables proper compression with subsampling and also
enables optimization of internal settings.
Result: From 34MiB down to 12MiB with no noticable difference.
It can happen that an application uses a QMainWindow in its widget hierachy for
its features but does not correspond to an actual window. Only alter those
toolbars for the unified look whose QMainWindows are actual windows and as such
have a window decoration.
BUG:427410
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.
I also renamed Breeze to Breeze Light because it's very awkward to talk about the Breeze project when it's not clear whether or not you're talking about just the light version.
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)
Neal Gompa
Dominic Hayes
l10n daemon script
Laurent Montel
David Redondo
Carson Black
Fabian Vogt
Andreas Haratzis
Noah Davis
Vlad Zahorodnii
Nate Graham
Lindsay Roberts
Bhushan Shah
Heiko Becker
Niccolò Venerandi