https://bugs.kde.org/show_bug.cgi?id=395725
Marian <mariana...@icloud.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mariana...@icloud.com
--- Comment #20 from Marian <mariana...@icloud.com> ---
I will comment on this rather than open a new issue (what I was about to do).
This should be moved to kwin/decorations. I am currently working on a fork of
breeze and encountered the mechanics for this to be the following:
People will usually triggere this when using transparencies with rounded
corners. The desktop blur effect system plugin also highlights this but it's
actually not it's fault. It just makes visible how your window is being drawn
by Qt. Yes breeze does have support for blur (although not being accessible by
any configuration, so you might debate about what is "support" I guess),
because it does not at all depend on the decoration. It depends on the desktop
effect plugin. Any Qt drawn opacity below 1.0 will get the blur from the plugin
applied if it is activated. Breeze even has the compatibility boolean in its
JSON file set to false. But this is not important to the issue.
The QDecoration Class (which is archived by Qt since 4.8 and even back then was
flagged for _embedded_ Linux) is used to paint the foreground chunk of the
window decorations in breeze. It is the top level widget window. Qt is explicit
about this:
>From https://doc.qt.io/archives/qt-4.8/qwidget.html#autoFillBackground-prop
[...]
autoFillBackground : bool
This property holds whether the widget background is filled automatically.
If enabled, this property will cause Qt to fill the background of the widget
before invoking the paint event. The color used is defined by the
QPalette::Window color role from the widget's palette.
In addition, Windows are always filled with QPalette::Window, unless the
WA_OpaquePaintEvent or WA_NoSystemBackground attributes are set.
This property cannot be turned off (i.e., set to false) if a widget's parent
has a static gradient for its background.
[...]
Emphasis on the second last sentence.
Further you will find that the first painting action for a non-special (shaded
etc.) situation for breeze is this:
painter->fillRect(rect(), Qt::transparent);
So according to the Qt documentation our top level QRect from the Decoration
Class is now drawn with a transparent QtGlobalColor. If you delete this line it
will default to the same transparent color.
You can change this to Qt::red or any other prominent color to clearly make
this visible. After changing the color of the top level rectangle you can see
that it is always drawn as simple QRect, be it with XRender or OpenGL. If you
apply transparency in this situation you can clearly appreciate the underlying
top level rectangle.
The blur effect visually reinforces this construction by applying the blur to
the transparent top level QRect. Now suddenly it is not just transparent
anymore.
I see two possible approaches to this which I'm not able to implement myself:
1. Make the top level widget a rounded rectangle. This seems to be difficult to
me as Qt does not provide a direct approach for this. The QRect Class has no
such implementation.
2. Find a way to not have the top level widget be filled. The mentioned article
may be of help.
--
You are receiving this mail because:
You are watching all bug changes.
