[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Child frame alpha (not background)
From: |
Po Lu |
Subject: |
Re: Child frame alpha (not background) |
Date: |
Mon, 13 Nov 2023 14:43:41 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
[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.