From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#9181: 24.0.50; Alpha transparency no longer works Date: Fri, 29 Jul 2011 11:34:15 +0200 Message-ID: <4E327E97.4070200@swipnet.se> References: <87mxg2t7oa.fsf@killer.sedemnajst.si> <4E3151B9.7070704@harpegolden.net> <4E31EBC3.8050303@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1311932109 31168 80.91.229.12 (29 Jul 2011 09:35:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2011 09:35:09 +0000 (UTC) Cc: Luka Novsak , 9181@debbugs.gnu.org To: David De La Harpe Golden Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 29 11:35:04 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QmjTD-0005yY-Hl for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jul 2011 11:35:03 +0200 Original-Received: from localhost ([::1]:58312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmjTD-0004yu-4X for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jul 2011 05:35:03 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmjT9-0004yT-VI for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2011 05:35:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmjT8-0003XT-Ea for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2011 05:34:59 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmjT8-0003XP-D3 for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2011 05:34:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QmjTB-0001tU-PJ; Fri, 29 Jul 2011 05:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Jul 2011 09:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9181 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9181-submit@debbugs.gnu.org id=B9181.13119320827251 (code B ref 9181); Fri, 29 Jul 2011 09:35:01 +0000 Original-Received: (at 9181) by debbugs.gnu.org; 29 Jul 2011 09:34:42 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QmjSr-0001st-Ji for submit@debbugs.gnu.org; Fri, 29 Jul 2011 05:34:42 -0400 Original-Received: from smtprelay-h22.telenor.se ([195.54.99.197]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QmjSp-0001sj-PS for 9181@debbugs.gnu.org; Fri, 29 Jul 2011 05:34:40 -0400 Original-Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 72F6DE9222 for <9181@debbugs.gnu.org>; Fri, 29 Jul 2011 11:34:17 +0200 (CEST) X-SENDER-IP: [85.225.45.26] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlZFACl+Mk5V4S0aPGdsb2JhbAA1AQEBAQIBAQImFSIkAQUMDBoCBSILAgIJAwIBAgECGQUNCxsHDgEOAQGET6MTCwEBAQE3Moh8AgKub5EhgSuEBoEQBJBuhxKLXw X-IronPort-AV: E=Sophos;i="4.67,286,1309730400"; d="scan'208";a="210743591" Original-Received: from c-1a2de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.26]) by ipb1.telenor.se with ESMTP; 29 Jul 2011 11:34:16 +0200 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 12BD97FA059; Fri, 29 Jul 2011 11:34:16 +0200 (CEST) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <4E31EBC3.8050303@harpegolden.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 29 Jul 2011 05:35:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:49692 Archived-At: 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.