emacs-devel
[Top][All Lists]
Advanced

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

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


From: David De La Harpe Golden
Subject: Re: Changes 2009-07-15/16 in branch?
Date: Mon, 27 Jul 2009 21:14:06 +0100
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701)

Richard Stallman wrote:
    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?




Well, my understanding (possibly outdated) is the NS port only uses its alpha value in very limited fashion. It just lets you sort of see what's underneath the emacs window.

It's AFAIK not doing the in-emacs alpha-blending I proposed (without working implementation...) a while back to allow translucent overlays - e.g. a translucent region letting highlighted text "underneath" show through /with highlighting still visible/. That would be much more useful.

But if I was doing that in-emacs alphablending (not saying I will successfully, just if...), I personally would not use the peculiar NS chosen syntax for colors with alpha values. I'd probably prefer to have separate float face properties, foreground-alpha and background-alpha, to allow me to continue to use named X11 colors
i.e. background: "midnightblue" background-alpha: 0.5

(yes, I suppose it would be possible to support both external
and in-color-name alphas, messily.  But if I was doing that, I'm still
not keen on the NS chosen syntax. Note how css and x11 both nowadays
user separated values e.g. rgb(r, g, b) or rgb:r/g/b )

OTOH, color names are currently parsed in a platform dependent manner anyway - i.e. you can't expect a color specification that works on X11 to work on w32. X11 emacs actually does a call out to XParseColor() on X11, which means emacs might get end-user defined named colors for all it knows*, so I'm not sure there's any particular harm in letting the NS port have its own interpretation of the color name strings.

* e.g. Place following in ~/.xcms.txt

XCMS_COLORDB_START 0.1
Blobby    rgb:7fe2/ffe1/331a
XCMS_COLORDB_END

(note that the syntax demands a _tab_ between color name
and rgb: spec)

then do
export XCMSDB=~/.xcms.txt

Now run x11 emacs, and note how  if you enter Blobby (or indeed some
rgb:r/g/b value) in emacs for a color, x11 emacs recognises it.





reply via email to

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