From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.bugs Subject: bug#9181: 24.0.50; Alpha transparency no longer works Date: Fri, 29 Jul 2011 00:07:47 +0100 Message-ID: <4E31EBC3.8050303@harpegolden.net> References: <87mxg2t7oa.fsf@killer.sedemnajst.si> <4E3151B9.7070704@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 1311894496 12528 80.91.229.12 (28 Jul 2011 23:08:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Jul 2011 23:08:16 +0000 (UTC) Cc: 9181@debbugs.gnu.org To: Luka Novsak Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 29 01:08:12 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 1QmZgZ-0007Z0-W7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jul 2011 01:08:12 +0200 Original-Received: from localhost ([::1]:51688 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmZgZ-0004p3-GF for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Jul 2011 19:08:11 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmZgQ-0004Ql-NH for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2011 19:08:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmZgP-0005wF-E6 for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2011 19:08:02 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmZgP-0005w4-5w for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2011 19:08:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QmZgQ-0004dl-9y; Thu, 28 Jul 2011 19:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David De La Harpe Golden Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Jul 2011 23:08:02 +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.131189447417823 (code B ref 9181); Thu, 28 Jul 2011 23:08:02 +0000 Original-Received: (at 9181) by debbugs.gnu.org; 28 Jul 2011 23:07:54 +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 1QmZgI-0004dQ-4d for submit@debbugs.gnu.org; Thu, 28 Jul 2011 19:07:54 -0400 Original-Received: from harpegolden.net ([65.99.215.13]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QmZgF-0004dJ-Ma for 9181@debbugs.gnu.org; Thu, 28 Jul 2011 19:07:52 -0400 Original-Received: from [87.198.47.59] (87-198-47-59.ptr.magnet.ie [87.198.47.59]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id D721A683B9; Fri, 29 Jul 2011 00:07:48 +0100 (IST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 28 Jul 2011 19:08:02 -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:49686 Archived-At: On 28/07/11 19:16, Luka Novsak wrote: > Yes, I'm running xcompmgr; alpha transparency is working fine in other > applications. > > I've noticed a peculiar detail--this problem does not occur when > running X without a window manager, say if I only run xcompmgr and > emacs in my X session. I've tried this with multiple window managers, > so it doesn't seem to be the fault of either one. Oh yeah... xcompmgr only looks for _NET_WM_WINDOW_OPACITY on truly toplevel (i.e. direct children of root window) windows. It's working when there's no window manager, because then emacs' window is a direct child of the root window. But in a typical window manager case, emacs' window is of course reparented under the window manager's frame window, so emacs setting the property on its own window (with the other _NET_WM properties) doesn't work for xcompmgr. It may be working for your other apps depending on how you or they set their opacity (using "transset" will set the property on the window manager frame, for example). However, note that the current code _does_ work when using now-typical combined compositing window managers rather than xcompmgr (hence my works-for-me), because they, as a matter of current practice, _do_ look for the property on the application windows they're managing, which makes sense really, reasonable place for it with all the other similar properties. *** 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) 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) 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.