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
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
