Subject: bug#9181: 24.0.50; Alpha transparency no longer works

From: Jan Djärv <[email-masked]>
Date: Fri, 29 Jul 2011 11:34:15 +0200

David De La Harpe Golden skrev 2011-07-29 01:07:

> *** So why _was_ it working? emacs used to special-case in
> xterm.c/x_set_frame_alpha() that set the property on the parent window of the
> emacs window rather than the emacs window itself [1], it got removed in trunk
> rev 104095 to fix bug #8608 (Jan cc'd)
>

First of all, not all window managers reparent the application top level 
windows.  So putting a property blindly in the parent window does not work for 
those window managers.

Secondly, it is the job of the window manager to replicate the property from 
the application window to any window it may put as parent to that window.
http://lists.freedesktop.org/archives/xdg/2003-December/001413.html:
"Window managers MUST forward the value of this property to any enclosing
frame window."

Note however that _NET_WM_WINDOW_OPACITY isn't in EWMH, so this is not a 
formal specification.

But from my point of view, this is a window manager bug, not a bug in Emacs.

> I for one am not at all sure restoring it is the right thing to do, it seems
> problematic. Emacs doesn't notionally "own" the window manager frame around
> it, and some reparenting window managers could actually use more than one
> level of window between the root and the app window too anyway. (I don't think
> reparenting window managers actually do typically copy the property up in
> practice as suggested under #8608, either, I'm afraid. That would be rather
> unique handling of the property AFAIK)

Reverting the change breaks other window managers as you say.  If a window 
manager does not copy the property it must have a very good rationale for not 
doing so, since the only text about _NET_WM_WINDOW_OPACITY specifically 
specifies that a window manager must do so.

>
> So maybe setting the property in both places (either optionally or always) is
> the best we can do, at least if we want to support xcompmgr.
>

It is not xcompmgr that is buggy, it it the window manager.  But the bug 
report does not say what window manager is used.

	Jan D.