[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9181: 24.0.50; Alpha transparency no longer works
From: |
Jan Djärv |
Subject: |
bug#9181: 24.0.50; Alpha transparency no longer works |
Date: |
Fri, 29 Jul 2011 11:34:15 +0200 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 |
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.