Child frame alpha (not background)

Child frame alpha (not background)

[Psionic K]

While developing champagne.el, I'm sure I saw child frame alpha (not just
background) was working at some point.  I think it has regressed.  Code
here:
https://github.com/positron-solutions/champagne/blob/master/lisp/champagne.el#L189-L190

I tried out PGTK and a number of window managers on 29 and master.  I never
got full transparency working again.  I've been using XFCE forever.  If
anyone sees the simpler alpha frame property working, it would be helpful
to know your window manager and Emacs version for bisection.

The background transparency is pretty sweet.  Can't wait to polish
keypression some more.  https://youtube.com/shorts/cXB7EnTcAD4

-- 

남백호
대표 겸 공동 창업자
포지트론

Re: Child frame alpha (not background)

[Po Lu]

Psionic K <psionik@positron.solutions> writes:

> While developing champagne.el, I'm sure I saw child frame alpha (not just
> background) was working at some point.  I think it has regressed.  Code
> here:
> https://github.com/positron-solutions/champagne/blob/master/lisp/champagne.el#L189-L190
>
> I tried out PGTK and a number of window managers on 29 and master.  I never
> got full transparency working again.  I've been using XFCE forever.  If
> anyone sees the simpler alpha frame property working, it would be helpful
> to know your window manager and Emacs version for bisection.
>
> The background transparency is pretty sweet.  Can't wait to polish
> keypression some more.  https://youtube.com/shorts/cXB7EnTcAD4

Neither alpha nor alpha-background has ever functioned under child
frames, since non-toplevel windows cannot be composited on any window
system we support.  This is prerequisite for superimposing the contents
of any number of translucent windows upon their parents and siblings.

I have long been of the opinion that child frames are a misfeature; it
is better to create a frame that is kept above all others, and to
position such a frame manually.

Re: Child frame alpha (not background)

[Po Lu]

[Please use "Reply All", so that the mailing list receives all replies.]

Psionic K <psionik@positron.solutions> writes:

> Sounds like the expectation is that applications should composite
> internally if they want to draw more things in a given window.  Given
> that tiling exists, asking for windows but not wanting them managed by
> a window manager seems counter to a user-choice focused data model.

X "windows" are what other toolkits dub "widgets," top-level windows
being windows whose parents are the root window or frame windows created
by a window manager.  A window manager cannot control top-level windows
on which the override-redirect property is set, so such constrants as
tiling cannot be imposed on them.

> If that's true, the right solution is to properly implement a child
> frame that uses drawing rather than repurposing the window
> functionality.

Anyway, patches to this end are welcome as always, but until then frames
will remain sub-optimal as user-interface elements.