After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745060 - GTK+ theme, shadow border does not work
GTK+ theme, shadow border does not work
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-02-23 23:55 UTC by Alberts Muktupāvels
Modified: 2016-06-23 14:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
frames: Don't clip out "invisible" parts of frames (2.63 KB, patch)
2016-06-23 12:37 UTC, Florian Müllner
committed Details | Review
frames: "Initialize" frame background (1.49 KB, patch)
2016-06-23 12:37 UTC, Florian Müllner
committed Details | Review

Description Alberts Muktupāvels 2015-02-23 23:55:48 UTC
There is at least one bug with GTK+ theme.

Adwaita theme has 1px shadow that is used as border:
box-shadow: 0 0 0 1px rgba(0, 0, 0, 0.23);

This border is not visible. It is rendered by gtk, but it is cut off. In this case frame width and height should be 2px bigger so this shadow border is not cut off.
Comment 1 Alberts Muktupāvels 2015-02-24 01:54:57 UTC
It looks like problem is only with gnome-terminal...
Comment 2 Sebastian Keller 2015-04-02 21:32:14 UTC
This also happens with dialog windows, like "zenity --info" for example. It is especially visible in the backdrop case there.
Comment 3 Hussam Al-Tayeb 2016-06-21 23:46:35 UTC
So far most of the cases where I have seen this have been windows the output the following in gnome-terminal:

Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

One example is tracker-preferences.

zenity --info also outputs "Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged." and shows the bug.

Perhaps this may give a lead to where the glitch is.
Comment 4 Florian Müllner 2016-06-21 23:50:07 UTC
This was actually fixed a while ago ...

*** This bug has been marked as a duplicate of bug 752794 ***
Comment 5 Hussam Al-Tayeb 2016-06-22 00:05:16 UTC
Hi Florian. I remember bug 752794. It solved some windows.
But this one is a different issue.
I have gtk+ 3.20.6 and bug 752794 is fixed.
But this one isn't.
Please consider reopening.
Comment 6 Alberts Muktupāvels 2016-06-22 06:34:51 UTC
Florian, did you try zenity dialog? This is still problem with git master.
Comment 7 Florian Müllner 2016-06-23 12:37:33 UTC
Created attachment 330250 [details] [review]
frames: Don't clip out "invisible" parts of frames

The GTK+ theme may draw parts of the decorations outside the actual
frame. Since commit f9db65f47f we make sure that the frame is big
enough to account for any overdrawing, however as we still clip the
cairo context to the actual frame before drawing the decorations,
those parts aren't actually painted.
This issue is not very obvious for most frames, as they use a non-rgba
visual where the unpainted parts appear black, which gives the expected
result with many themes once the shape mask is applied (as the mask does
include any overdrawn parts). For frames using an rgba visual however,
unpainted parts are transparent, so any overdrawn decorations are clearly
missing.
Fix this by only clipping out the client area when drawing decorations.
Comment 8 Florian Müllner 2016-06-23 12:37:39 UTC
Created attachment 330251 [details] [review]
frames: "Initialize" frame background

Frames are painted on the frame window according to the GTK+ theme.
Depending on the target's visual, this means either drawing over
a black destination or a fully transparent one. So in cases where
the theme doesn't paint decorations with full opacity, decorations
for windows with an rgba visual look different from those with a
non-rgba visual. Using an rgba visual for all frames independent
from the client's visual can potentially break clients, so our
only option for a consistent appearance is to explicitly initialize
the frame background to black before painting the theme's decoration
on top.
Comment 9 Hussam Al-Tayeb 2016-06-23 14:43:20 UTC
It looks perfect now with those patches.
Comment 10 Rui Matos 2016-06-23 14:45:05 UTC
Review of attachment 330251 [details] [review]:

ok
Comment 11 Rui Matos 2016-06-23 14:45:20 UTC
Review of attachment 330250 [details] [review]:

looks good
Comment 12 Florian Müllner 2016-06-23 14:48:45 UTC
Attachment 330250 [details] pushed as c61dfa7 - frames: Don't clip out "invisible" parts of frames
Attachment 330251 [details] pushed as a174c18 - frames: "Initialize" frame background