bug#9181: 24.0.50; Alpha transparency no longer works

[David De La Harpe Golden <david@harpegolden.net>]

On 03/08/11 12:50, Jan Djärv wrote:


>> ...I've yet to encounter any that propagate the property...
>
> Metacity (gnome 2.x) and unity-decorator (Ubunty 11.04) does.
>

Shrug. Metacity 2.34.1 does not appear to do so on my system. Dunno 
about unity, not in a position to try it without excessive messing 
about. Setting opacity on the client window absolutely does _work_ (i.e. 
make the window translucent) under metacity with its compositing 
enabled, but it doesn't actually propagate the window property as such. 
i.e. If I disable metacity builtin compositing and use xcompmgr with 
metacity instead, it's not picked up, which I checked in case xprop and 
xwininfo -tree were lying to me (they apparently weren't).

> Typical compsiting managers are separate programs from the window
> manager (compiz for example), so they don't know what window is the
> client window.

Except they aren't anymore, most compositing managers you encounter 
nowadays _are_ combined compositing/window managers e.g. kwin, xfwm4, 
metacity. Also compiz: nowadays typically run as a sort of combined 
(though multiprocess) compositing window manager with a "compiz window 
decorator"  rather than a separate true traditional wm. The gtk+ one 
looks like metacity, uses metacity themes ...isn't metacity. And is 
apparently non-reparenting => no propagation involved anyway.

I do understand the motivation for the propagation hack, but it's just 
not what current versions of currently typical desktop env wms seem to 
be doing (AFAICT on my debian/unstable system).  Again, either way, 
emacs blindly setting the property on its parent is the wrong thing.  I 
just suspect filing bugs upstream to window managers for the 
non-propagation at this stage is something of a lost cause.