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 730016 - Menubars don't have background-color
Menubars don't have background-color
Status: RESOLVED FIXED
Product: gnome-themes-standard
Classification: Core
Component: Adwaita GTK3 theme
3.12.x
Other All
: Normal minor
: ---
Assigned To: gnome-themes-standard-maint
gnome-themes-standard-maint
Depends on:
Blocks:
 
 
Reported: 2014-05-12 15:33 UTC by Egmont Koblinger
Modified: 2014-05-20 13:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
maybe fix? (646 bytes, patch)
2014-05-12 18:26 UTC, Egmont Koblinger
reviewed Details | Review
gtk3: Provide a background-color for menubars (796 bytes, patch)
2014-05-15 16:30 UTC, Debarshi Ray
committed Details | Review
gnome-terminal transparency demo (1.45 KB, patch)
2014-05-20 13:24 UTC, Egmont Koblinger
none Details | Review

Description Egmont Koblinger 2014-05-12 15:33:52 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.
Comment 1 Christian Persch 2014-05-12 15:39:10 UTC
Not reproducible here on 15 tries (but my gtk+/adwaita build is a few weeks old). Is this with gnome-shell?
Comment 2 Egmont Koblinger 2014-05-12 15:46:44 UTC
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.
Comment 3 Christian Persch 2014-05-12 15:59:00 UTC
Is this with the ubuntu theme, or adwaita?

It would be great if you could try to repro this on gtk+ master + adwaita master.
Comment 4 Debarshi Ray 2014-05-12 16:07:58 UTC
I have never seen this happen while working on bug 729884 I have f20 + gnome-3-12 + adwaita.
Comment 5 Egmont Koblinger 2014-05-12 16:56:38 UTC
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 :)
Comment 6 Matthias Clasen 2014-05-12 17:23:26 UTC
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.
Comment 7 Egmont Koblinger 2014-05-12 18:02:29 UTC
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.
Comment 8 Egmont Koblinger 2014-05-12 18:26:24 UTC
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.
Comment 9 Debarshi Ray 2014-05-12 18:34:04 UTC
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.
Comment 10 Debarshi Ray 2014-05-12 18:35:26 UTC
As per comment 6, it is the theme that is broken.
Comment 11 Egmont Koblinger 2014-05-12 18:41:38 UTC
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?
Comment 12 Christian Persch 2014-05-12 18:43:09 UTC
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
Comment 13 Debarshi Ray 2014-05-12 19:47:26 UTC
(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."
Comment 14 Egmont Koblinger 2014-05-12 20:59:15 UTC
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?
Comment 15 Egmont Koblinger 2014-05-12 21:18:51 UTC
Reported upstream: https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1318821
Comment 16 Lars Karlitski 2014-05-13 12:14:28 UTC
Indeed, this is an issue with Ubuntu's themes.
Comment 17 Matthias Clasen 2014-05-13 14:34:15 UTC
(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
Comment 18 Debarshi Ray 2014-05-14 11:01:58 UTC
Menus in Adwaita have the same issue as toolbars in Ambiance/Radiance.
Comment 19 Debarshi Ray 2014-05-15 14:02:42 UTC
Reassigning to gnome-themes-standard.
Comment 20 Debarshi Ray 2014-05-15 16:30:13 UTC
Created attachment 276613 [details] [review]
gtk3: Provide a background-color for menubars
Comment 21 Jakub Steiner 2014-05-15 16:39:04 UTC
Review of attachment 276613 [details] [review]:

looks good.
Comment 22 Egmont Koblinger 2014-05-20 13:24:21 UTC
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.