Open Bug 837761 Opened 11 years ago Updated 2 years ago

[GTK Themes] No way to render rounded menus

Categories

(Core :: Widget: Gtk, enhancement)

18 Branch
x86
Linux
enhancement

Tracking

()

People

(Reporter: b7.10110111, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130202172056

Steps to reproduce:

I'm developing oxygen-gtk and would like to implement rounded menus also for Firefox. For now we just fall back to square menus which look not quite Oxygen and are not what we really desire to have.


Actual results:

When a theme renders ARGB image to a GdkDrawable passed to it, the result is black color when transparency is expected. This is understandable, because the drawable has color depth of 24 bit. At the same time, if we don't render anything at all in that drawable, the menus are transparent (maybe I just was lucky enought to get this), which makes me think that target X11 windows do have ARGB color map and color depth of 32 bit.


Expected results:

So, it'd be nice if firefox passed a 32bit drawable to the theme (to its draw_box() method in particular) so that it could render rounded menus and copied it to target windows so that this could work - OR use native GTK menus as e.g. Chromium does.
Severity: normal → enhancement
Component: Untriaged → Theme
Component: Theme → Widget: Gtk
Product: Firefox → Core
What I suspect we want is to change moz_gtk_widget_get_colormap() to take a (Moz)GtkThemeWidgetType argument and check the colormap of the associated widget.

nsNativeThemeGTK::GetWidgetTransparency() would also need updating to return eTransparent for menus, preferably only when the theme uses translucent colormaps.

Bug 829425 is related.

(In reply to Ruslan Kabatsayev from comment #0)
> At the same time, if we don't render
> anything at all in that drawable, the menus are transparent (maybe I just
> was lucky enought to get this), which makes me think that target X11 windows
> do have ARGB color map and color depth of 32 bit.

I don't know why that would happen.  Bug 798157 should mean that windows are only transparent if GetWidgetTransparency() doesn't return opaque.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.