Despite the name, Complementary colors are used more like an always available set of dark color scheme colors. This means that in situations where you'd expect colors to always be dark, they become bright white with Breeze Dark because they were given Complementary colors rather than hardcoded dark colors. I don't think all these instances where the complementary color group is used like that will be fixed before Plasma 5.21 is released, so I'm making the Breeze Dark Complementary color set use normal Breeze Dark colors.
There is a special case for comboboxes when drawing a styled frame, but for
some reason it didn't actually check whether the QQuickItem is a combobox,
there was only a comment...
This adds the check, which means that QQuickItems get a proper frame now
instead of a combobox popup.
Currently the separators in headers are drawn at the right edge for each
section. That makes it visible on the rightmost edge of a header, directly
adjacent to the surrounding frame, surrounding in a 2px wide line.
(For RTL it's the reverse)
Avoid the double line by moving the separator to the adjacent "HeaderEmptyArea"
instead, which is only visible when necessary.
As a side effect, this commit fixes the check for whether a section is "last"
for invisible headers and RTL layouts.
Paint events MUST not change the state of things. This is especially
important within style code that is used in many apps that we do not
control.
Doing it in polish is better. It's still not ideal to adjust geometry in
the style, but at least this is where we have a similar hook for
QDockWidget so hopefully we know this pattern is acceptable.
BUG: 427311
This reverts commit 7e678c344b and the followup.
A B
+-----+ +-----+ C
| | |XXXXX| +---+
| XXX | |X X| |XXX|
| XCX | |X C X| |XCX|
| XXX | |X X| |XXX|
| | |XXXXX| +---+
+-----+ +-----+
Initially it was A, the referenced commit changed it to be B instead, which
created a 1px gap between frame and content, and the followup avoids that gap
by adjusting the frame width, resulting in C.
Although it's consistent, it leads to a worse apperance in places where the 1px
margin between frame and rect was expected.
7e678c34 removed the offsets from all sides, but that created a gap at the
right and bottom edges. This is because the frame is actually just 1px on
each side, but Frame_FrameWidth didn't match that.
kde4breeze changes the color scheme when it runs as part of kconf_update,
but at that time some applications (including kwin) might already be running.
Those need to be notified of the change.
BUG: 428771
The documentation for 'QPainter::drawRoundedRect' [1]
says:
"A filled rectangle has a size of rect.size(). A stroked
rectangle has a size of rect.size() plus the pen width."
Therefore, the frame rect passed to that method needs to
be adjusted according to the pen width for the case where
the rect is stroked (i.e. an outline exists), and no
adjustement is needed when the rect is not stroked so
that
[size of rect] + [outline width] = [wanted total size]
The default pen size is 1 (which is also the value
of 'PenWidth::Frame' used to calculate the radius for the
outline a few lines further down).
For the case that an outline exists, the adjustment of
the rect already happens in the call to 'Helper::strokedRect',
so there is no need for reducing the rect by one additional
pixel on each side, which resulted in the frame border
unnecessarily not being right at the inner edge of the
rect, but one additional pixel "further inside".
It looks like the additional adjustment was originally added
by commit 3dbcea7e59
("Changed frame width to 2, to cope with focus rect.",
2014-07-30), later adapted by commit
f288c34c3e
("Render 2px focused outline *inside* frames rather than outside",
2014-08-11) and commit 2985b4cb6b
("use one pixel for focus frame instead of 2", 2014-09-22).
While 'Metrics::Frame_FrameWidth' still has the value 2,
it is not used here at all, so the default pen width of 1
applies.
Therefore, drop the extra adjustment in order for the
stroke to be drawn right at the edge of the rect.
[1] https://doc.qt.io/qt-5/qpainter.html#drawRoundedRect
BUG: 428973
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.
Noah Davis
l10n daemon script
Carson Black
Fabian Vogt
David Edmundson
Michael Weghorn
Neal Gompa
Dominic Hayes
Laurent Montel
David Redondo
Andreas Haratzis
Vlad Zahorodnii
Nate Graham