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.
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
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.
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.
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.
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! :-)
But speaking as a user I don't really care how they look.
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.
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.