Comment 10 for bug 195929

(In reply to comment #7)
> Just so things are clear, I am the current maintainer of gtk-engines.

Welcome to the party :-)

> This is a lot an issue that is a lot more complex than just "using
> transparency instead of drawing the window background color as part of the
> widget".

Sure.

> We *need* to draw the background color in a lot of cases (GtkEntry,
> GtkProgressBar)!

I believe you, but why is that?

> I don't want to go into too much detail here, but I would not be suprised if
> this is not fixable in GTK+. (I have not investigated this possibility too
> much.)

That depends on how much you are willing to change GTK+ or the themes, I guess, since it's possible to design themes that don't show these problems.

> So this means the only way to achieve the correct behaviour would be to
> somehow work together and hint the engine/theme that filling the background
> is not necessary.

Interesting. Can you say more about how that might work?

> (Hm, I shouldn't missuse this bug to complain, but I do not like mozillas GTK+
> emulation stuff in some ways. For example you could at least give the
> GtkWindow or the GtkFixed a name with gtk_widget_set_name to make it possible
> to create sane special cases for mozilla.)

That's a good idea, but I would call it something more like "HTML" because Webkit/GTK+ is using this code too.

What other suggestions do you have?

One thing I really want is the ability to pass a cairo_t directly down to a theme at least for those themes that draw using cairo. Right now when we have to draw a widget with rotation or scale, or to a non-X surface (printing), we have to use horrible hacks involving temporary pixmaps. When the widget is partially transparent the hacks are even more horrible.