bug#9181: 24.0.50; Alpha transparency no longer works

[David De La Harpe Golden <david@harpegolden.net>]

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.