GNOME Bugzilla – Bug 769006
Adwaita: border too dark, hard to identify overlapping black windows
Last modified: 2018-05-02 17:19:16 UTC
Hi, in recent gtk versions the window border is too dark, and when two "black" windows overlap (e.g. two terminals, two "eog" windows) it's very hard to identify visually which part belongs to which window. Some users thought that this was a problem with CSD/SSD[1], but maybe it's just a theme issue. I tried to fix the issue by using more contrast for the border, while still trying to be subtle, this is the snippet I came up with (I have it in an "overlay theme" which imports Adwaita and then apply some fixups): .ssd decoration { box-shadow: 0 0 0 1px rgba(46, 52, 54, 0.9); } decoration { box-shadow: 0 3px 9px 1px rgba(0, 0, 0, 0.5), 0 0 0 1px rgba(46, 52, 54, 0.9); } The attached screenshot shows the intended result, the fix works with xterms and eog under metacity/gnome-flashback, but when I use mutter/gnome-shell I can only see a slight improvement with eog (CSD) but no changes for xterms or gnome-terminal windows (SSD). Any idea about how to fix the issue in a more generic way? Would these changes conflict with the rationale in #722563 ? Thanks, Antonio [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821410
Created attachment 331835 [details] Adwaita: fix borders for black windows Attaching the screenshot failed the first time; trying a second time.
Nice, I don't think there can be a fix more generic than this one, I'd try a sligthly darker gray for the 'border shadow' so I will be noticeable only on a black background.
My doubt was also about this change working for metacity/gnome-panel but not for mutter/gnome-shell. I'll try editing the full Adwaita theme file and see if I have to touch something else. Thanks, Antonio
Mutter pulls its theming from the gtk+ theme nowadays, IIRC the window shadow is hardcoded though :-/ Let me cc Florian.
(In reply to Lapo Calamandrei from comment #4) > Mutter pulls its theming from the gtk+ theme nowadays, IIRC the window > shadow is hardcoded though :-/ Mutter uses GTK+'s gtk_render_* API to draw frame decorations. We still use our own shadow code, as we need to add shadows to undecorated windows (as popups or docks) as well where we don't have a frame window for GTK to draw to. That said: - we still should pick up any shadow specified by the GTK theme for decorated windows, it will just be shown in addition to our own shadows - we could actually stop adding shadows to decorated windows and rely on the GTK theme to add one (In reply to Antonio Ospite from comment #0) > When I use mutter/gnome-shell I can only see a slight improvement with > eog (CSD) but no changes for xterms or gnome-terminal windows (SSD). What mutter version is this? There have been some[0] issues[1] with decorations drawn outside the visible frame in the past, but to the best of my knowledge those should be fixed now. [0] https://bugzilla.gnome.org/show_bug.cgi?id=752794 [1] https://bugzilla.gnome.org/show_bug.cgi?id=745060
(In reply to Florian Müllner from comment #5) > (In reply to Antonio Ospite from comment #0) > > When I use mutter/gnome-shell I can only see a slight improvement with > > eog (CSD) but no changes for xterms or gnome-terminal windows (SSD). > > What mutter version is this? There have been some[0] issues[1] with > decorations drawn outside the visible frame in the past, but to the best of > my knowledge those should be fixed now. > > [0] https://bugzilla.gnome.org/show_bug.cgi?id=752794 > [1] https://bugzilla.gnome.org/show_bug.cgi?id=745060 I tried with mutter 3.20.3 which AFAICS does not contain https://bugzilla.gnome.org/show_bug.cgi?id=745060 I'll try my theme changes with 3.21.4 then. Thanks, Antonio
Thanks Florian, so this should be fixable. Antonio the proposed color is too bright though, it should be darker then the darkest background color we have on the dark adwaita variant (#232729), since that border should be visible there and that's a more common case than black on black. Looking at adwaita we already don't use black on the dark variant, not on for the normal bright one though.
(In reply to Antonio Ospite from comment #6) > I tried with mutter 3.20.3 which AFAICS does not contain > https://bugzilla.gnome.org/show_bug.cgi?id=745060 If the terminals you tested your changes with support a translucent background, then they are affected by the issue fixed in that bug.
Hi I managed to build mutter 3.21.4 as a debian package and installed it in my system but gnome-shell 3.20.3 doesn't play well with it (gdm doesn't even show the login screen), from journalctl I can see that this has something to do with the latest clutter changes in mutter: lug 24 09:39:31 jcn org.gnome.Shell.desktop[3530]: Unable to init server: Impossibile connettersi: Connessione rifiutata lug 24 09:39:31 jcn org.gnome.Shell.desktop[3530]: (gnome-shell:3530): Clutter-CRITICAL **: Unable to initialize Clutter: Impossibile inizializzare Gdk lug 24 09:39:31 jcn org.gnome.Shell.desktop[3530]: (gnome-shell:3530): mutter-WARNING **: Unable to initialize Clutter. lug 24 09:39:31 jcn gnome-session[3039]: gnome-session-binary[3039]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 lug 24 09:39:31 jcn gnome-session-binary[3039]: Unrecoverable failure in required component org.gnome.Shell.desktop lug 24 09:39:31 jcn gnome-session-binary[3039]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 lug 24 09:39:31 jcn gdm-launch-environment][2448]: pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm ... lug 24 09:39:36 jcn org.gnome.Shell.desktop[3677]: (gnome-shell:3677): Clutter-CRITICAL **: The Clutter backend is not a X11 backend lug 24 09:39:36 jcn kernel: gnome-shell[3677]: segfault at 10 ip 00007f9f5be9efe4 sp 00007fffea123210 error 4 in libmutter.so.0.0.0[7f9f5be47000+118000] lug 24 09:39:36 jcn gnome-session[3654]: gnome-session-binary[3654]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11 lug 24 09:39:36 jcn gnome-session-binary[3654]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11 I don't know if just compiling the latest gnome-shell is enough to fix it, but this is my only system and it's also not super-fast so I would rather not mess too much with it, if you guys can take a look yourself at the original issue with the latest mutter I would appreciate it. Thanks a lot, Antonio
(In reply to Antonio Ospite from comment #9) > Hi I managed to build mutter 3.21.4 as a debian package and installed it in > my system but gnome-shell 3.20.3 doesn't play well with it Yes, you cannot mix stable and unstable versions like that. > I don't know if just compiling the latest gnome-shell is enough to fix it, > but this is my only system and it's also not super-fast so I would rather > not mess too much with it The latest gnome-shell will have other dependencies - at least gsettings-desktop-schemas comes to mind. I'm not saying it's impossible, but rebuilding your distro's stable mutter package with the patches from bug 745060 applied will be much less painful - the patches should apply cleanly, and you won't need to update anything else.
(In reply to Florian Müllner from comment #10) [...] > rebuilding your distro's stable mutter package with the patches from bug > 745060 applied will be much less painful - the patches should apply cleanly, > and you won't need to update anything else. That's a better plan indeed, I can do that :)
OK, I need to buy more brown paper bags... the changes from bug 745060 are already in 3.20.3. I'll double check why the borders weren't showing up with mutter and get back. BTW Lapo, do you see the issue with black on black windows yourself?
Mutter does have problems with GTK+ theme, I noticed that when I was adding GTK+ theme support in Metacity (based on mutter), but due lack of time I have not reported bug... decoration { box-shadow: 0 0 0 20px, rgba(255, 0, 0, 0.6); border: 10px solid green; } Adding above to ~/.config/gtk-3.0/gtk.css is enough to see problems: - box-shadow is darker on ssd window if compared to csd window - border does not work at all If needed I can create screenshots, mutter was re-built from current master.
(In reply to Alberts Muktupāvels from comment #13) > - box-shadow is darker on ssd window if compared to csd window That's likely mutter's own shadow getting painted over the decoration's shadow. The current expectation is that the "real" window shadow (that is not a shadow serving as border replacement) is added by the client for CSD windows and the compositor for SSD windows.
(In reply to Florian Müllner from comment #14) > (In reply to Alberts Muktupāvels from comment #13) > > - box-shadow is darker on ssd window if compared to csd window > > That's likely mutter's own shadow getting painted over the decoration's > shadow. The current expectation is that the "real" window shadow (that is > not a shadow serving as border replacement) is added by the client for CSD > windows and the compositor for SSD windows. Does mutter draw 20px big shadows? I will attach two screenshots that use decoration node with css from my previous comment.
Created attachment 332230 [details] metacity
Created attachment 332231 [details] mutter
(In reply to Florian Müllner from comment #14) > That's likely mutter's own shadow getting painted over the decoration's > shadow. The current expectation is that the "real" window shadow (that is In screenshot I see mutter's shadow, so I don't think that it is painted over.
(In reply to Alberts Muktupāvels from comment #17) > Created attachment 332231 [details] > mutter Yeah, that looks like a different issue.
Created attachment 332270 [details] Difference between SSD border between Mutter and Metacity (In reply to Florian Müllner from comment #14) > (In reply to Alberts Muktupāvels from comment #13) > > - box-shadow is darker on ssd window if compared to csd window > > That's likely mutter's own shadow getting painted over the decoration's > shadow. The current expectation is that the "real" window shadow (that is > not a shadow serving as border replacement) is added by the client for CSD > windows and the compositor for SSD windows. Can this have anything to do with my confusion about the border missing with Mutter? Maybe it was not missing, it was just too dark for me to see it. See the attached image made with this style: decoration { box-shadow: 0 3px 9px 1px rgba(0, 0, 0, 0.5), 0 0 0 1px rgba(255, 255, 0, 0.5); } .ssd decoration { box-shadow: 0 0 0 1px rgba(255, 255, 0, 0.5); } When the color is _transparent_ the SSD border with Mutter is not only darker than the CSD border, as Alberts says, is also darker compared to the SSD border in Metacity. AFAICS solid colors are rendered equal, and CSD borders also look the same between Metacity and Mutter, whether they are transparent or not. So before fixing the border color in the theme maybe we should have the box-shadow border rendered equal in Metacity and Mutter for the SSD case too. Thanks, Antonio
1) Missing green border in my screenshot can be fixed by calling gtk_render_frame (with META_STYLE_ELEMENT_FRAME) in meta_ui_frame_get_mask. 2) Unrelated, but there is bug with HiDPI scaling. In meta_frame_layout_draw_with_style GdkRectange is used to store calculated values, but... 2001px width divided by scale will be 1000px, but it should be 1000.5. 3) titlebar_rect != visible_rect, titlebar should not include border from frame. 4) And for darker shadow - any chance that blend_string used with cogl_pipeline_set_layer_combine in meta_shaped_texture.c is not correct? Without understanding what I am doing I changed blend_string to "RGB = REPLACE (PREVIOUS) A = MODULATE (PREVIOUS, TEXTURE)" (found here [0]) and now it looks like shadow is equal between csd and ssd windows. [0] https://developer.gnome.org/cogl-2.0-experimental/stable/cogl-Blend-Strings.html
Ping. Florian, have you had the chance to look at what Alberts proposes at item 4. in comment #21? Thanks, Antonio.
@Florian, the issue about mutter showing dimmer borders for server side windows is still present in mutter 3.22.1 Do you prefer a separate bug report for that? After the mutter problem is fixed we can come back discussing the theming issue in this report. Thanks, Antonio
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
The windows border is still too dark in gtk3 3.22.28 and overlapping black windows are not usable.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/648.