Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 27 Jul 2009 13:41:04 -0400, Richard Stallman <address@hidden> 
>>>>> 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
                                address@hidden