[Top][All Lists]

[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.
"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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]