Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Thursday 6 April 2006

GNOME Themes In HTML

A while ago we turned off GTK themes in HTML content in Mozilla cairo builds because of some bugs and performance issues. I wanted to get them turned on again and fixed some of the bugs, and then ran into a fundamental problem in the Clearlooks engine (which Novell's new theme is based on), and which probably applies to other themes.

The general problem is that the Clearlooks design simply isn't suitable for use with HTML. The immediate problem is that it wants to render the borders of buttons, textboxes and other widgets with a gradient based on the colors of their containing window (from the window's inset_dark to inset_light). This is no good for HTML because in HTML the widget could be (and often is) drawn over any color background, or an image, or any combination of anything, so one can't just "set the right colors" and be sure to get good results. This is not a technical problem, it is a problem with the design of Clearlooks ... it wouldn't look good even if you had a pure GTK+ application using Clearlooks widgets over complex backgrounds.

I'm not sure where to go from here. I think we need theme designers to think about what they want for themes in HTML content, and then we can figure out the best way to implement it. Certainly, Web uses will have to be taken into account during theme design. I plan to talk about this with Novell's theme artists when I get a chance.


Comments

Racer
Would it be possible to make the colors of the button have alpha transparency (to pick up the background color)?
Richard Stellingwerff
As the author of Clearlooks, I feel the need to reply.
Clearlooks is one of the very themes that draws an inset gradient, but it's easy to make Clearlooks not draw it.
The inset gradient is only drawn if the widget's style specifies a border of three pixels. If you set this to two pixels, the inset will not be drawn.
Since two pixels is the default for pretty much every theme, I wonder if you can't just force it to two pixels for all buttons.
If this isn't a satisfying solution, then maybe there should be a way to match HTML-rendered widgets using the gtkrc. widget_class "*.HTML.GtkButton" for example.
That way I can force Clearlooks to not draw the inset for widgets-on-HTML.
Millennium
Alas, the Mac has been going through this same sort of problem.
The users, unfortunately, don't care. They want their "REAL NATIVE AQUA WIDGETS!!!!!1!!one" even though -just as you point out- a widget set that can't respond to styling is bad for the Web. It doesnt matter; they want something that "feels like their operating system", and they don't care how it looks other than that.
Just a heads-up. True UI-zealotry (as in "My Widgets, Right or Wrong") isn't as common on X11-based systems, but it's something you might run into, either now or in the future.
Eike Hein
"The problem remains that many GTK2 themes are quite a bit more involved design-wise than the Windows widgets or the current Firefox form widgets, and can look out of place in websites not designed to accomodate them. [...] Trying to go native is more trouble than it's worth."
From http://weblogs.mozillazine.org/roc/archives/2006/02/cairo_linux_and_gtk2_themes.html
Told you so, hm? Good luck trying to evangelize theme designers to forego creative license and come up with designs always neutral enough to fit arbitrary web content.
Robert O'Callahan
Racer: not with current GDK APIs.
Richard: hi! I did notice that. Novell's theme uses a border width of 3, unfortunately, for buttons and textboxes at least. Also, even if you don't draw the inset gradient, you still fill the button area with the window background color, which shows at the corners of the button. I wonder why this is necessary? (I can actually prevent that by hacking the bg_gc in the style to make it GDK_NOOP, but it's uuuugly and breaks other things.)
Having widget classes for HTML widgets sounds interesting, but wouldn't that make HTML widgets not so consistent with regular widgets?
Eike: I remain confident that we'll work something out that doesn't require radical changes. I'll have the last laugh! :-)
ant
I think one way of fixing it would be to have GTK themes come with two sets of widgets where one is designed to look right on image backgrounds or whatever and the other is for solid colours.
But speaking as a user I don't really care how they look.
Calvin Walton
Other programs are already using the gtk widgets on an arbitrary image background: gnome-panel is an example. I think it looks fine with clearlooks, although the "inset" line below the button is noticable, it doesn't really look bad.. And, for reference, a screenshot: http://kepstin.gotnull.net/clearlooksbg.png
Richard Stellingwerff
Robert O'Callahan: Well yes, in the cairo version at least, I manually draw the background behind buttons and entry's because of a Firefox bug.
If I don't manually draw the background on the down-arrow-button in the location bar, you get a white background. Since this looks ugly, I created a little workaround that draws a background if the x,y position of the button is -1, which is the case for all widgets in Firefox.
If you want to see the workaround code, grep for "firefox" in http://cvs.gnome.org/viewcvs/gtk-engines/engines/clearlooks/src/clearlooks_style.c?rev=1.56&view=markup
At least in Clearlooks cairo, the way to fix this would be by setting the x/y position to their, you might guess, x/y position.
If I don't make sense, I'll try to explain better. Feel free to email me at remenic AT gmail DOT com.
Robert O'Callahan
Calvin: with that theme and that background it doesn't look so bad. With Gilouche (which specifies a 3px border, whereas your screenshot is only using a 2px border I believe) and a black or gray background, it looks pretty bad.
Richard: I was referring to this in cl_draw_button:
if (!widget || !GTK_IS_NOTEBOOK (widget->parent))
{
gdk_draw_rectangle (window, bg_gc, FALSE, x, y, width-1, height-1);
Now that I look at it again, I see that it's only drawing the rectangle edge, not filling, but it's still a problem.
Would you mind CCing yourself to
https://bugzilla.mozilla.org/show_bug.cgi?id=329846
? That's probably the best place for this discussion.
I think the reason you're not getting a real x/y position from Firefox is because we only have one GTK widget of each type, it's just a proxy that we use to draw all widgets of that type. It's a hack. We really need a style API that lets us draw without an actual GTK widget. In the meantime we should figure out what you're working around and fix it in Firefox.