425877 - Tell the GTK theme engine that Mozilla is requesting the drawing, so it can fix its quirks

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Michael Ventnor]

Attachment: Patch

I can't think of a better title.

A big problem is abound with GTK themes nowadays. The kinds of quirks they draw with their engine are necessary for a conventional GTK app yet cause complete and total ugliness when drawn on a Mozilla window, or worse, a web page.

The best and most compatible way to solve this problem is to give every widget a trademark name so the engine can determine that they are drawing for Mozilla, and can adjust their behaviour to remove GTK quirks or add Mozilla quirks.

Changing the name is the way most GTK developers agree is the best way to solve this issue. This way, theme engine authors can fix things like the grey filler pixels near the rounded corners of a textbox.

Comment 1

[Michael Ventnor]

Oh, and I moved some declarations to fix some warnings, hope you don't mind.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Should we use WebGtkWidget instead of MozillaGtkWidget for Webkit friendliness?

Comment 3

[Michael Ventnor]

I don't think so, Moz or Mozilla is used all throughout the code they're using so they don't seem to care, and having "Mozilla" in the name means a far less chance of name clashes and a far greater chance of theme authors knowing why they need to do what they're doing.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+#define SET_MOZILLA_BRAND(widget) gtk_widget_set_name(widget, "MozillaGtkWidget")

I don't think this really has anything to do with "brand". Also, macros suck. So how about a static function called SetWidgetName?

Comment 5

[Michael Ventnor]

Attachment: Patch 2

Comment 6

[Michael Ventnor]

Comment on attachment 312541 [details] [diff] [review]
Patch 2

We need this so Firefox 3 doesn't have a lifespan of minor GTK widget glitches.

Comment 7

[Reed Loden [:reed]]

Checking in widget/src/gtk2/gtk2drawing.c;
/cvsroot/mozilla/widget/src/gtk2/gtk2drawing.c,v  <--  gtk2drawing.c
new revision: 1.103; previous revision: 1.102
done

Comment 8

[Julien "_FrnchFrgg_" RIVAUD]

I don't think it's necessary to set a name on every widget we use. As long as the proto window has a distinctive name, GTK themes/engines will be able to match our widgets, since they have a facility to match "for every widget which is a child of a <name> named widget".

Comment 9

[Benjamin Berg]

I think that a subclass of GtkWindow for the "toplevel" window that is used in mozilla would be the most usefull thing (on the gtkrc level).

With the current method of setting a name on every widget it is impossible to change the style of eg. all of mozilla's comboboboxes. This is easy if the window is a subclass, as then something like
  widget_class "Mozilla.*<GtkComboBox>" style "..."
would be possible in the gtkrc.

Comment 10

[Ian Spence]

According to http://www.gtk.org/tutorial1.2/gtk_tut-21.html#ss21.1 that is exactly what this gives us

Instead of 

widget_class "Mozilla.*<GtkComboBox>" style "..."

We would have

widget "MozillaGtkWidget.*<GtkComboBox>" style "..."

Comment 11

[Benjamin Berg]

Heh, GTK+ 1.2 ;-)

Not quite right. It is true that in a "widget" match the class name will be used if no name has been set on the widget. So

  widget "MozillaGtkWidget.*GtkComboBox" style "..."

will work if the combobox does not have a name set. It will stop working if a name is set on the combobox, though.

Also the subclass lookup (what the angle brackets are doing) does not work in the "widget" match. This means that

  widget "MozillaGtkWidget.*<GtkComboBox>" style "..."

does not have any effect at all. The angle brackets mean that subclasses of GtkComboBox (ie. GtkComboBoxEntry) will also be styled with the match.

This means that having a subclass has some advantages for theme authors.

Comment 12

[Benjamin Berg]

Sorry if I created some confusion ...

If you just set a name on the window, then this is a huge improvement. This is also better than a name on every widget (as it can be sanely handled in the gtkrc).

Now a subclass of GtkWindow may be a bit nicer in some cases, but is *not* neccessary. This is because the "widget_class" match got some extra features in GTK+ 2.10 (ie. the subclass matching with the '<>').