Re: [Mac OS X] [Win32] Frame-transparency patch

[Juanma Barranquero]

> > Perhaps the easiest fix is just define the constants yourself.
> I've done.

I'm not sure whether it would be better to protect these with #ifndef, i.e.

  #ifndef LWA_ALPHA
  #define LWA_ALPHA 2
  #endif

Take a look at other potential redefinition on the sources to see
what's usually done.

Another thing: you could easily extend the functions to deal with any
frame, for example:

  (defun set-active-alpha (alpha &optional frame)
    "Set the opacity of FRAME in active state to ALPHA.
ALPHA can take a value between 0.0 (invisible) and 1.0 (completely opaque).
When called interactively, prompt for the value of the opacity to set.
FRAME defaults to the selected frame.  To get the frame's current
active alpha value state, use `frame-parameters'."
    (interactive "nActive alpha (0.0 - 1.0): ")
    (when (or (< alpha 0.0) (> alpha 1.0))
      (error "Alpha value must be between 0.0 and 1.0, inclusive"))
    (modify-frame-parameters frame
                             (list (cons 'active-alpha alpha))))

> >>  - Better still would be to document what the ALPHA-VALUE is and what
> >> is its range (0.0 to 1.0, I assume, but it is not said anywhere).

In the function below you'll see I've reworded slightly the docstring
regarding the range of ALPHA. (I've also added error checking.)

> > wraparound. It'd be better to restrict the values entered to the
> > correct range.
> Both done.

I would have expected that entering 1.1 would produce an error. I
think it is better to do it at the frame.el level, but that depends on
who/how x_set_(active|inactive|frame)_alpha are going to be used. BTW,
I've not checked but, do the C functions need to be exported by
frame.h? It seems like they could be static.

> Could you check new patch.

I've checked it now on two-frame setups. When one frame is behind the
other and the cursor moves on the foreground frame, there's some
unexpected redisplay caused by the background frame. Also, I've seen
one case of a 4NT.exe shell not redisplaying correctly after
minimizing a partially transparent Emacs frame, but that could be a
4NT problem.

All in all, I find the feature interesting, although obviously
post-22.1 stuff (at least IMO).

-- 
                    /L/e/k/t/u