Re: GTK Widgets drawing an undesired background

[Lovelace Luquette <luquette bu edu>]

On Sun, 30 Sep 2007, Johan Ersvik wrote:

> Hi Lovelace,
> Interesting topic. Have you managed to find a solution yet?

Only partially--I ended up leaving it alone after a few days of playing 
around.  Although there were a few things of interest:
  * As of gtk-2.12, we've got a function for setting a widget's opacity,
    so presumably I could use this to try to completely opacify the
    widgets which cause this black background.  That's a pretty bad
    solution, though.
  * I noticed a pixmap based theme on gnome-look.org recently which used a
    semi-transparent pixmap on the toolbar.  What was interesting is that
    the transparent portion of the toolbar didn't reveal the black
    background I was seeing--rather, it revealed the background of the GTK
    window, untouched.  This is still baffling me, and I've yet to ask the
    author any questions about it nor have I taken a peek at the code for
    the pixmap engine.

Anyway, on to the problem: I only took interest in two cases of the 
background drawing: the menubar and toolbar widgets.  The toolbar widget 
proved most interesting because when it isn't detachable (i.e.: it has no 
handlebox parent), it doesn't draw any weird background.  So I moved on to 
modifying the handlebox widget to see if I could figure out where the 
weird behavior was coming from.  (If you want to see what the behavior 
looks like, I can save you the time of writing a "null" engine and just 
send you my code.  Just let me know if you'd like it.  I used Richard 
Stellingwerf's "The Widget Factory" to do this testing, although in 
particular all you need is a small GTK app that uses a gtkhandlebox on 
its toolbar.)

My hunch was (and still is) that any widget which creates its own gdk 
window will have this unwanted behavior.  So, I followed code through to 
the X11 implementation of gdk_window_new() to figure out what X internals 
were being used to handle the new GDK windows.  Sure enough, 
XCreateWindow() was being called with its background_pixel attribute 
activated in the attr mask and with a value of BlackPixel().  I was pretty 
sure this was going to be the deal; but it turned out pretty 
non-conclusive.  I changed the BlackPixel call to the WhitePixel call just 
to see if I could invert the behavior, but the toolbars embedded in 
handleboxes still retained their flat black background.

At this point I started trying to create some debugging code that would 
dump pixmaps at certain points in the code path, but I ended up never 
getting any truly useful debugging functions written (though I tried a 
whole bunch of different ways and learned a good deal about GDK and X11 
internals along the way).  As a result, I never really figured out where 
in the code path GDK (or possibly GTK) is creating these black 
backgrounds.

I'm _really_ convinced that this behavior is coming from the GDK windows, 
though.  It even seems to correlate with what I've seen from that recent 
theme on gnome-look that uses the pixmap engine: when you call 
XCreateWindow, you can either specify a pixmap or a background pixel for 
filling.  If you _do_ specify a pixmap, then the background pixel is 
supposedly ignored and the background is created, obviously, by tiling the
pixmap you supply.  (This also ties in to Zentara's recommendation about 
setting the background pixmaps to "none" in the gtkrc file.)

I'd jump back into messing with this if I had the time, but I'm pretty 
swamped with other stuff.  I think this sort of thing is probably more 
appropriate for the actual gtk dev list (and possibly someone there could 
give a definitive answer right off the bat); but if anyone does figure out 
what's going on here, I'd love to hear it.

Happy hacking,
Joe Luquette