GNU bug report logs - #9181
24.0.50; Alpha transparency no longer works

Previous Next

Package: emacs;

Reported by: Luka Novsak <lnovsak <at> gmail.com>

Date: Wed, 27 Jul 2011 19:17:03 UTC

Severity: normal

Found in version 24.0.50

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


Message #44 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Luka Novsak <lnovsak <at> gmail.com>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 03 Aug 2011 16:12:03 +0100
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.





This bug report was last modified 13 years and 295 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.