GNOME Bugzilla – Bug 730016
Menubars don't have background-color
Last modified: 2014-05-20 13:24:21 UTC
./src/vte-2.91 -T 1 With an approx 50% chance the header (the bar with the copy/paste/input buttons) is opaque, as expected. With an approx 50% chance the header (except for the buttons themselves) is fully transparent.
Not reproducible here on 15 tries (but my gtk+/adwaita build is a few weeks old). Is this with gnome-shell?
My gtk+/everything is from ubuntu trusty, except vte/g-t. Reproducable both with unity/compiz (whatever ubuntu's default is), and with gnome-shell. Could easily be something that's been fixed in Gtk+. Or a race condition that's less likely to occur on your system. Dunno.
Is this with the ubuntu theme, or adwaita? It would be great if you could try to repro this on gtk+ master + adwaita master.
I have never seen this happen while working on bug 729884 I have f20 + gnome-3-12 + adwaita.
Ambiance (ubuntu default), Radiance -> reproducible Adwaita, High Contrast -> can't reproduce (still using ubuntu trusty's gtk-3.10.8 and other stock packages) Can you guys try to reproduce with a different theme? It's more useful if you can reproduce than if I can't :)
GTK_THEME=Raleigh GTK_CSD=1 vte-2.91 -T 50 comes up with a totally seethrough toolbar here. The headerbar is solid though. And Adwaita and HighContrast are fine. This is just a case of a theme not drawing toolbar background.
Broken since https://git.gnome.org/browse/vte/commit/?id=4431fd96 (bug 729884) If I remove the 'app_paintable = true' line, everything is fine again. If I make that line unconditional (execute even without transparency) then the toolbar is randomly the correct shade of gray, or black.
Created attachment 276399 [details] [review] maybe fix? I'm not sure what problem this "app_paintable" is supposed to solve (it works perfectly for me without this option), but since it's connected to the terminal area only (and not the UI chrome) being transparent, shouldn't it belong to the terminal itself rather than the whole window? See the patch, it works for me.
Review of attachment 276399 [details] [review]: ::: src/app.vala @@ +75,3 @@ + if (App.Options.transparency_percent != 0) { + terminal.app_paintable = true; + } No, this is wrong. The VteTerminal widget already sets its app-paintable property, but that is not enough. The toplevel window needs to be marked as app-paintable. Please do read bug 729884 for the reasons behind it.
As per comment 6, it is the theme that is broken.
Oh, it's too complicated for me :) I'll file a bugreport, but what shall I tell them, what is missing/broken in their theme?
Company chpe: the 50% thing is definitely a bug somewhere, we'd like to be consistent chpe I can't repro (gnome-shell 3.8, gtk+ git a few weeks old), so it's quite possibly obsolete... Company chpe: but yes, removing the background from a GtkWindow may very well cause all of the GtkWindow to be transparent - and when the headerbar is transparent, too, ... Company i've not looked at the drawing ode of GtkWindow since the csd stuff landed, so I don't know how and what we actually draw there
(In reply to comment #11) > Oh, it's too complicated for me :) GTK+ which sets an opaque region on GtkWindows (gtk+ commit 3c2c3ab6) that are not marked as app-paintable. This is supposed to be a hint to compositing window managers so that they do not draw anything that is behind such a window. If a window is marked as app-paintable then this opaque region is not set. Therefore, things obstructed by the window are still drawn, which is what you want if you have a transparent widget in the window. This is why a GtkWindow that contains a transparent VteTerminal needs to be marked as app-paintable nowadays. I say "nowadays" because the introduction of this gtk+ change broke the transparency in vteapp. Now, this does depend on whether the compositing window manager is looking at the hint given by gtk+, and ofcourse other things like the theme, etc.. While trying to nail down why the transparency stopped working in vteapp, I remember trying it out both on unity and gnome-shell. The transparency worked in unity but not in gnome-shell. My assumption is that unity/compiz does not look at the hint given by gtk+ regarding opaque regions, while gnome-shell/mutter does. I think that is what you mean when you say that it works for you. Now I don't know much about the theme, but I think it is basically what mclasen said in comment 6: "This is just a case of a theme not drawing toolbar background."
Placing this in {Ambiance,Radiance}/gtk-3.0/gtk-widgets.css: GtkToolbar { background-color: @bg_color; } or adding this to the already existing .toolbar section: .toolbar { [...] background-color: @bg_color; [...] } makes the bug go away. Matthias: setting GTK_THEME has no effect for me, do you have any wild guess why this could be?
Reported upstream: https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1318821
Indeed, this is an issue with Ubuntu's themes.
(In reply to comment #14) > Matthias: setting GTK_THEME has no effect for me, do you have any wild guess > why this could be? Not-so-wild guess: you're using 3.10, and GTK_THEME was introduced in 3.11
Menus in Adwaita have the same issue as toolbars in Ambiance/Radiance.
Reassigning to gnome-themes-standard.
Created attachment 276613 [details] [review] gtk3: Provide a background-color for menubars
Review of attachment 276613 [details] [review]: looks good.
Created attachment 276859 [details] [review] gnome-terminal transparency demo For further reference, I attach a proof-of-concept patch that adds transparency to gnome-terminal 3.13. This is to help reveal more themes that lack some color definitions. The original bug was spotted using vteapp, which uses a toolbar. G-t has a menubar and a notebook instead. Ubuntu's Ambiance/Radiance suffer from the same transparency bug in the notebook's inactive tab (I'll report to them), perhaps other themes are effected too.