Comment 12 for bug 195929

I think the way to go would be to extend the engine API to provide additional entry points that take cairo_t parameters. I don't know how practical that is.

> The problem with the GtkEntry is that it consists of two X windows (one around
> everything, and one for the text area). Both of these windows are filled with
> base[NORMAL], ie. the background color for the text. So to get the rounded
> look we need to fill the background with the correct color.

It seems to me that in this case the outside window should be transparent instead of being prefilled with the text background color. Maybe that doesn't make sense for a GdkDrawable API but it would make sense for cairo_t API.

Another option is that using cairo, it is possible to draw with OPERATOR_SOURCE or OPERATOR_CLEAR and "knock out" some pixels, making them transparent or translucent where they're currently opaque. So it would be possible to actually make the area outside the rounded border transparent even if it started off with a solid color.

> The progress bar case would may be easier to fix. The problem here is that
> GTK+ caches the bar (without text) in a server side pixmap. I do not know
> what the reason for doing this is, however it means that we need to fill the
> background to prevent displaying uninitilized memory.

cairo would fix this again because you could cache an RGBA surface instead of a pixmap. (Actually the RGBA surface would be an XRender pixmap.)

So it seems to me that GTK+ should move towards a cairo-based API for theme engines, then these problems can be fixed on the GTK+ side and we can have a better interface for our needs too.