so, a lot of people probably know that i’m playing around with some code that will let me test out ideas that we can merge into gnome-panel in the future. one of these ideas is the idea of using x compositing instead of the terrible hacks we have today to support transparency in the applets.
the approach, i thought, would be to simply paint alpha transparency onto the background of the applet. when the xembed was done, this would allow the background of the panel to be seen through the applet. or so my thinking went, at least…
turns out, this isn’t how it works at all. when you draw alpha onto the applet, it just draws the alpha straight onto the panel toplevel window. the result is that the panel itself becomes transparent (through to the desktop).
i got annoyed and started looking for places to complain about this insanity. i went to #cairo. there i found owen taylor, carl worth and keith packard, who all very patiently explained to me why i was wrong. after being told why what was happening was in fact the correct behaviour i went off and did an awful lot of learning. i now know what all of those xfixes, xdamage, xcomposite, xrender things mean.
i also coded a solution to the problem — an in-panel compositing manager. i’ve called it panelcompositebin. it’s a normal gtkbin. when you place a widget inside of it that has its own gdkwindow (like a gtkeventbox, or more usefully, a gtksocket/plug pair) it will composite the contents of that window onto the background of the parent containing it. the effect: real applet transparency without the awful hacks.
this code has potential to be used in other places, which is why i make it available here. i’ve also included a small test application. if you find other uses for it, please let me know. any feedback about bugs is also appreciated. you need gtc to build it.
one note: i don’t think anybody has ever done this before. as such, this code exposes a bug in the x.org server where expose events aren’t sent when they should be. it’s on keith’s todo list to fix it, but he’s a busy man. for now, in a fit of irony, i have added a timer to the code to generate synthetic expose events once per second :)
meta-note: keith thinks the bug lies in the miValidateTree code in xorg in mi/mivaltree.c. i find this code utterly incomprehensible, so i’m not much help there. if anyone else wants to try their hand at tracking the bug down, i’ve written a small test app to help you: exposetest. the goal is to get the parent to see the expose events.
screenshot?
Is that what you looking for ?
http://desrt.mcmaster.ca/random/dropshadow.png