GNOME Bugzilla – Bug 723740
Right-click menus have no border (or anything else to stop them blending into a white app)
Last modified: 2014-02-11 03:31:33 UTC
With GTK+ 3.11.5 on Fedora Rawhide, when I right-click in a GTK+3 app, the menu has no border or anything. If the area of the app behind it is white, the menu blends entirely into the app. It's a bit distracting. I see https://git.gnome.org/browse/gtk+/commit/?id=f13b3e3aeb5dae2da0a2c62599d8d5f24bfd4e46 , but I got the impression popovers were something different from right-click menus, so I don't think this is the same bug as that. Will attach screenshot.
Huh, the right-click menu doesn't appear in the screenshot. So, no screenshot. :)
Confirmed.
Looks like a theme issue to me
I don't think so - tried to reproduce it here and running the application with GDK_RGBA=0 shows the menu border correctly.
Then it must be mutter. It does: static gboolean meta_window_actor_has_shadow (MetaWindowActor *self) { ... /* * Do not add shadows to non-opaque windows; eventually we should generate * a shadow from the input shape for such windows. */ if (is_non_opaque (self)) return FALSE; /* * Add shadows to override redirect windows (e.g., Gtk menus). */ if (priv->window->override_redirect) return TRUE; } I guess that needs to be ordered the other way around, or maybe is_non_opaque needs to be changed
No, unless we're guaranteed that the ARGB32 surface is an opaque square. We should probably revert the change to use ARGB32 surfaces by default. I *completely* forgot that we don't put shadows on ARGB32 windows. This will also break shadows for any non-CSD GTK+ app as well.
> I *completely* forgot that we don't put shadows on ARGB32 windows. This will > also break shadows for any non-CSD GTK+ app as well. It doesn't - you put shadows on every window with a frame, regardless of visual. Menus are the only thing thats broken. But I agree that we should probably just revert this, since we don't actually need it for our theme, and it causes problems.