GNU bug report logs - #9181
24.0.50; Alpha transparency no longer works

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9181 in the body.
You can then email your comments to 9181 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Luka Novsak <lnovsak <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Alpha transparency no longer works
Date: Mon, 25 Jul 2011 22:41:09 +0200

My last build of emacs from source checked out of the trunk on
2011-07-21 broke transparency. My former build was several weeks old, so
can't say how old this is exactly.

Starting from emacs -Q I do (set-frame-parameter (selected-frame) 'alpha
'(90 90)), which should(?) work, but doesn't anymore.


In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4)
 of 2011-07-21 on killer
Windowing system distributor `The X.Org Foundation', version 11.0.11002902
Important settings:
  value of $LC_ALL: en_US.utf8
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-netsplit-mode: t
  erc-log-mode: t
  erc-truncate-mode: t
  eldoc-mode: t
  icomplete-mode: t
  global-subword-mode: t
  subword-mode: t
  erc-highlight-nicknames-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  nxhtml-menu-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Checking 87 files in /usr/local/share/emacs/24.0.50/lisp/calc...
Checking 65 files in /usr/local/share/emacs/24.0.50/lisp/obsolete...
Checking 1 files in /usr/local/share/emacs/24.0.50/leim...
Checking for load-path shadows...done
GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4) of 2011-07-21 on killer
delete-backward-char: Text is read-only
Auto-saving...done
Mark set [2 times]
Quit
Message modified; kill anyway? (y or n)  y

Load-path shadows:
/home/luka/.emacs.d/nxhtml/tests/ert hides /usr/local/share/emacs/24.0.50/lisp/emacs-lisp/ert

Features:
(shadow sort fortune mail-extr message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
emacsbug ind-util sh-script executable image-mode tramp-sh shell
tramp-cache help-mode view compile nxml-uchnm rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok
conf-mode newcomment iso-transl org-wl org-w3m org-vm org-rmail org-mhe
org-mew org-irc org-jsinfo org-infojs org-html org-exp ob-exp
org-exp-blocks org-info org-gnus org-docview org-bibtex org-bbdb
org-habit org-agenda tramp tramp-compat tramp-loaddefs multi-isearch
network-stream auth-source eieio password-cache starttls tls erc-menu
erc-join erc-ring erc-networks erc-pcomplete erc-track erc-match
erc-netsplit erc-log erc-truncate eldoc server paren icomplete subword
slime-repl my-look color-theme-subdued color-theme-less
color-theme-hober2 color-theme-gruber-darker color-theme-arjen-new
color-theme sendmail rfc2047 rfc2045 ietf-drums reporter my-ruby
my-python my-php php-mode add-log etags cc-langs cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
speedbar sb-image ezimage dframe assoc my-org org warnings ob-emacs-lisp
ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys
ob ob-eval org-complete pcomplete org-list org-faces org-compat
org-entities org-macs noutline outline cal-menu calendar cal-loaddefs
my-gnus gnus gnus-ems nnheader gnus-util mail-utils mm-util mail-prsvr
my-erc erc-highlight-nicknames erc-button erc-fill erc-stamp wid-edit
erc-goodies erc erc-backend erc-compat format-spec slime byte-opt
bytecomp byte-compile cconv macroexp derived apropos hideshow easymenu
pp comint ring hyperspec thingatpt browse-url idomenu imenu ido
clojure-mode regexp-opt android-mode easy-mmode edmacro kmacro cl
flymake-files advice help-fns advice-preload flymakemsg nxhtml-autostart
nxhtml-autoload majmodpri vc-git nxhtml-menu web-autoload nxhtml-base
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

-- 
Luka Novsak

Wagner's music is better than it sounds.
		-- Mark Twain

Message #8 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Luka Novsak <lnovsak <at> gmail.com>
Cc: 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Thu, 28 Jul 2011 13:10:33 +0100

On 25/07/11 21:41, Luka Novsak wrote:
> My last build of emacs from source checked out of the trunk on
> 2011-07-21 broke transparency. My former build was several weeks old, so
> can't say how old this is exactly.
>
> Starting from emacs -Q I do (set-frame-parameter (selected-frame) 'alpha
> '(90 90)), which should(?) work, but doesn't anymore.
>

Works for me (emacs trunk rev 105334)

Note this feature depends on compositing being active: all it does is 
set the relevant x11 window property to request the compositing manager 
render the window with some alpha.  So it has no effect if you've, say, 
turned off compositing (sometimes called "desktop effects") in a window 
manager capable of it (say XFCE), or have switched to a low-requirements 
desktop environment / window-manager that doesn't do it at all.

Message #11 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Luka Novsak <lnovsak <at> gmail.com>
To: 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Thu, 28 Jul 2011 20:16:25 +0200

On Thu, Jul 28, 2011 at 2:10 PM, David De La Harpe Golden
<david <at> harpegolden.net> wrote:
> Note this feature depends on compositing being active: all it does is set
> the relevant x11 window property to request the compositing manager render
> the window with some alpha.  So it has no effect if you've, say, turned off
> compositing (sometimes called "desktop effects") in a window manager capable
> of it (say XFCE), or have switched to a low-requirements desktop environment
> / window-manager that doesn't do it at all.

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.

For now I'm back to running Emacs 23.3.1.

Message #14 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Luka Novsak <lnovsak <at> gmail.com>
Cc: Djärv <jan.h.d <at> swipnet.se>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Fri, 29 Jul 2011 00:07:47 +0100

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.

Message #17 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: Luka Novsak <lnovsak <at> gmail.com>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
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.

Message #20 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Luka Novsak <lnovsak <at> gmail.com>
To: 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Fri, 29 Jul 2011 19:46:06 +0200

On Fri, Jul 29, 2011 at 11:34 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> It is not xcompmgr that is buggy, it it the window manager.  But the bug
> report does not say what window manager is used.

I first noticed this with Openbox, but I tried with a few others as well.

If the rules regarding setting this property are not found in the
specification, should emacs not for now stick with what works, and
just set it on the frame window, instead of relying on the window
manager, many of which do not seem to propagate this value to the
frame they create? This indeed seems to be standard practice with
every other piece of software which works with transparency (urxvt,
tint2, conky, ...).

Message #23 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Luka Novsak <lnovsak <at> gmail.com>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Sat, 30 Jul 2011 09:04:28 +0200

Hi.

Do not remove the debbugs address, sending again with it.

Luka Novsak skrev 2011-07-29 19:44:
> On Fri, Jul 29, 2011 at 11:34 AM, Jan Djärv<jan.h.d <at> swipnet.se>  wrote:
>> It is not xcompmgr that is buggy, it it the window manager.  But the bug
>> report does not say what window manager is used.
>
> I first noticed this with Openbox, but I tried with a few others as well.
>
> If the rules regarding setting this property are not found in the
> specification, should emacs not for now stick with what works, and
> just set it on the frame window, instead of relying on the window
> manager, many of which do not seem to propagate this value to the
> frame they create? This indeed seems to be standard practice with
> every other piece of software which works with transparency (urxvt,
> tint2, conky, ...).

None of urxvt, tint2 or conky sets _NET_WM_WINDOW_OPACITY.

    Jan D.

Message #26 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Luka Novsak <lnovsak <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Tue, 2 Aug 2011 22:23:06 +0200

On Sat, Jul 30, 2011 at 9:04 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> Do not remove the debbugs address, sending again with it.

Silly gmail did it.

Anyway, I've reported this upstream with Openbox, for one. However
even if they fix it, this will remain broken with many WMs still out
there.

Message #29 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Luka Novsak <lnovsak <at> gmail.com>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Tue, 02 Aug 2011 22:28:09 +0200

Luka Novsak <lnovsak <at> gmail.com> writes:

>> Do not remove the debbugs address, sending again with it.
>
> Silly gmail did it.

Gmail removes Cc addresses?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #32 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Luka Novsak <lnovsak <at> gmail.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Tue, 2 Aug 2011 22:49:43 +0200

On Tue, Aug 2, 2011 at 10:28 PM, Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote:
> Gmail removes Cc addresses?

Unless you use "reply all" instead of ordinary "reply". That is "a"
instead of "r" if you're using keybindings.

Message #35 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Luka Novsak <lnovsak <at> gmail.com>
Cc: 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 03 Aug 2011 10:13:03 +0200

Luka Novsak skrev 2011-08-02 22:23:
> On Sat, Jul 30, 2011 at 9:04 AM, Jan Djärv<jan.h.d <at> swipnet.se>  wrote:
>> Do not remove the debbugs address, sending again with it.
>
> Silly gmail did it.
>
> Anyway, I've reported this upstream with Openbox, for one. However
> even if they fix it, this will remain broken with many WMs still out
> there.

Which WM:s?

	Jan D.

Message #38 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Luka Novsak <lnovsak <at> gmail.com>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 03 Aug 2011 09:22:28 +0100

On 03/08/11 09:13, Jan Djärv wrote:
>
>
> Luka Novsak skrev 2011-08-02 22:23:
>> On Sat, Jul 30, 2011 at 9:04 AM, Jan Djärv<jan.h.d <at> swipnet.se> wrote:
>>> Do not remove the debbugs address, sending again with it.
>>
>> Silly gmail did it.
>>
>> Anyway, I've reported this upstream with Openbox, for one. However
>> even if they fix it, this will remain broken with many WMs still out
>> there.
>
> Which WM:s?
>

...I've yet to encounter any that propagate the property...

Now-typical combined compositing/window managers read the property from 
the client's window anyway (and don't propagate). If it is ever 
standardised, I'd kind of expect it to be standardised without the 
propagation (but still with the client's window being the right place 
for the client to set it, so the difference is somewhat academic).

Message #41 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: Luka Novsak <lnovsak <at> gmail.com>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 03 Aug 2011 13:50:54 +0200

David De La Harpe Golden skrev 2011-08-03 10:22:
> On 03/08/11 09:13, Jan Djärv wrote:
>>
>>
>> Luka Novsak skrev 2011-08-02 22:23:
>>> On Sat, Jul 30, 2011 at 9:04 AM, Jan Djärv<jan.h.d <at> swipnet.se> wrote:
>>>> Do not remove the debbugs address, sending again with it.
>>>
>>> Silly gmail did it.
>>>
>>> Anyway, I've reported this upstream with Openbox, for one. However
>>> even if they fix it, this will remain broken with many WMs still out
>>> there.
>>
>> Which WM:s?
>>
>
> ...I've yet to encounter any that propagate the property...

Metacity (gnome 2.x) and unity-decorator (Ubunty 11.04) does.

>
> Now-typical combined compositing/window managers read the property from the
> client's window anyway (and don't propagate). If it is ever standardised, I'd
> kind of expect it to be standardised without the propagation (but still with
> the client's window being the right place for the client to set it, so the
> difference is somewhat academic).
>

Typical compsiting managers are separate programs from the window manager 
(compiz for example), so they don't know what window is the client window.
That is why the propagate requirement is there.

	Jan D.

Message #44 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Luka Novsak <lnovsak <at> gmail.com>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 03 Aug 2011 16:12:03 +0100

On 03/08/11 12:50, Jan Djärv wrote:


>> ...I've yet to encounter any that propagate the property...
>
> Metacity (gnome 2.x) and unity-decorator (Ubunty 11.04) does.
>

Shrug. Metacity 2.34.1 does not appear to do so on my system. Dunno 
about unity, not in a position to try it without excessive messing 
about. Setting opacity on the client window absolutely does _work_ (i.e. 
make the window translucent) under metacity with its compositing 
enabled, but it doesn't actually propagate the window property as such. 
i.e. If I disable metacity builtin compositing and use xcompmgr with 
metacity instead, it's not picked up, which I checked in case xprop and 
xwininfo -tree were lying to me (they apparently weren't).

> Typical compsiting managers are separate programs from the window
> manager (compiz for example), so they don't know what window is the
> client window.

Except they aren't anymore, most compositing managers you encounter 
nowadays _are_ combined compositing/window managers e.g. kwin, xfwm4, 
metacity. Also compiz: nowadays typically run as a sort of combined 
(though multiprocess) compositing window manager with a "compiz window 
decorator"  rather than a separate true traditional wm. The gtk+ one 
looks like metacity, uses metacity themes ...isn't metacity. And is 
apparently non-reparenting => no propagation involved anyway.

I do understand the motivation for the propagation hack, but it's just 
not what current versions of currently typical desktop env wms seem to 
be doing (AFAICT on my debian/unstable system).  Again, either way, 
emacs blindly setting the property on its parent is the wrong thing.  I 
just suspect filing bugs upstream to window managers for the 
non-propagation at this stage is something of a lost cause.

Message #47 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: Luka Novsak <lnovsak <at> gmail.com>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 3 Aug 2011 19:29:15 +0200

On Wed, Aug 3, 2011 at 5:12 PM, David De La Harpe Golden
<david <at> harpegolden.net> wrote:
> Again, either way, emacs blindly
> setting the property on its parent is the wrong thing.

It's an unelegant hack, to be sure.

> I just suspect
> filing bugs upstream to window managers for the non-propagation at this
> stage is something of a lost cause.

Then there's that.

So unless emacs uses this workaround for now, it will not have
functioning alpha transparency when used in combination with a large
majority of window managers. As I've said, I've reported this upstream
with Openbox, and I suppose users of other wm's will do so when they
upgrade to emacs24, but there are A LOT of non-compliant window
managers out there, and it shouldn't be expected for this to change
any time soon.

Perhaps there should be a push for this to be formally specified in
the EWMH. The proposal for it seems to be many years old, and the
practice widespread, so I don't see why this hasn't happened yet.

Message #50 received at 9181 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Luka Novsak <lnovsak <at> gmail.com>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 9181 <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 03 Aug 2011 20:01:43 +0100

On 03/08/11 18:29, Luka Novsak wrote:

> So unless emacs uses this workaround for now, it will not have
> functioning alpha transparency
[with non-compositing non-property-propagating wms and xcompmgr]

Well, not settable from within emacs. The "transset" (and more 
full-featured derivative "transset-df") tools should still work though, 
as IIRC they walk the window hierarchy up to one below the root and thus 
set the property where xcompmgr expects it.

If a workaround were to be added back in to emacs, a similar walk would 
at least be better than just assuming the immediate parent is the right 
place to set it.

> when used in combination with a large majority of window managers.

OTOH, it will still work without the workaround with the various 
big-name-desktop-env default compositing window managers that likely 
account for the majority of actual desktops. Of course I'd expect non- 
big-name-desktops to be more popular with emacs users than users in 
general though.

> Perhaps there should be a push for this to be formally specified in
> the EWMH. The proposal for it seems to be many years old, and the
> practice widespread, so I don't see why this hasn't happened yet.

Well, it is ugly. e.g. A 2008 opinion expressed on the wm-spec-list was 
that it's an "ugly beast" ( 
http://mail.gnome.org/archives/wm-spec-list/2008-January/msg00020.html )

... And clients now have another, arguably much better (though somewhat 
more work for the client) way of specifying much more fine-grained 
(per-pixel) transparency, using an ARGB visual (AFAICS what "conky" you 
mentioned does).

What I'd _like_ to do is to *:

(i) alter emacs display-engine/face-resolution to do alphablending, and
(ii) emacs itself to use an ARGB visual overall

((i) and (ii) are actually only loosely related, you could have (i) 
without (ii) and vice-versa)

Thereby allowing e.g.
opaque text with translucent background (needs (i) and (ii)),
translucent region highlighting that doesn't obscure colored-background 
faces but rather blends over them (only needs (i)),
etc.

* bearing in mind I do have not much time right now to actually do it, 
and even if I (or someone else) did such a thing, it's not something 
that is likely to be able to go in-tree for months right now (feature 
freeze, and bidi being a large change in the general area), so it's not 
of immediate use to you.

Message #55 received at 9181-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Luka Novsak <lnovsak <at> gmail.com>
Cc: 9181-done <at> debbugs.gnu.org
Subject: Re: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Thu, 04 Aug 2011 13:14:06 +0200

Hello.

I've added setting the property on the topmost window manager window to work 
around broken WM:s.  Please test it.

Thanks,

	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.