GNU bug report logs -
#9181
24.0.50; Alpha transparency no longer works
Previous Next
Reported by: Luka Novsak <lnovsak <at> gmail.com>
Date: Wed, 27 Jul 2011 19:17:03 UTC
Severity: normal
Found in version 24.0.50
Done: Jan Djärv <jan.h.d <at> swipnet.se>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 13 years and 295 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.