28 Jul 2009 02:53
Re: Changes 2009-07-15/16 in branch?
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
2009-07-28 00:53:41 GMT
2009-07-28 00:53:41 GMT
>>>>> On Mon, 27 Jul 2009 13:41:04 -0400, Richard Stallman <rms <at> gnu.org> said: > What I'm concerning about with respect to the GNU policy is the > "alpha-component" (or maybe "alpha-channel" is more familiar) > support, which was added only for Cocoa. > Alpha-component/alpha-channel controls translucency of colors by > specifying how opaque it is. > Is this a feature users might actually want to use? I don't see > what it is good for. Can someone explain what a user might want to > do with this? Emacs 23 already has a frame opacity control feature whose design/implementation is different from what I mentioned above. I guess this was added because they considered that some users would want this kind of feature: Quote etc/NEWS: *** Emacs can now set the frame opacity. The opacity of a frame can be controlled by setting the `alpha' frame parameter. This only takes effect on a compositing window manager for the X Window System, such as Compiz, Beryl and Compiz Fusion, on Mac OS X, or on Windows 2000 and later versions of Windows. The alpha parameter should be an integer between 0 (transparent) and 100 (opaque), or a float number between 0.0 and 1.0. It can also be a cons cell (ACTIVE . INACTIVE), where ACTIVE is the opacity of an active frame and INACTIVE is the opacity of non-active frames. The variable `frame-alpha-lower-limit' defines a lower bound for the opacity; the default is 20. Some find its effect unsatisfactory because it makes both foreground and background colors translucent. Adrian says the alpha-component support in the NS port is superior and actually the latter can make background translucent while keeping foreground opaque. Actually the implementation of alpha-component support in the NS port has some annoying glitch as I pointed out in http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg01340.html . I think it's ridiculous to add such a feature to the release version * without broader discussion about the specification for such a general (i.e., non platform-specific) feature. * with a premature implementation only for a non-free platform. * with a risk of compatibility breakage in future. * with a risk of infringing the GNU policy. YAMAMOTO Mitsuharu mituharu <at> math.s.chiba-u.ac.jp