[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9181: 24.0.50; Alpha transparency no longer works

From: David De La Harpe Golden
Subject: bug#9181: 24.0.50; Alpha transparency no longer works
Date: Wed, 03 Aug 2011 20:01:43 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110626 Icedove/3.1.11

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)),

* 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]