Finishing Composite to handle transformed windows

[Andy Ritger]

The 'topmost' window approach seems to introduce a whole new set
of semantics and interactions that need to be defined; the notion
of multiple stacks of windows is intriguing but sounds like a
significant functional change... the questions it has raised in
this thread seem alarming.  Most frightening is how existing window
managers would need to be updated to be aware of topmost windows.
One of the brilliant things about Damage/Composite is how nearly
transparent (pun intended) it has been to existing X clients/window
managers.

If anything, the clip generation change to not be clipped by siblings
seems like a smaller behavioral change, which is appealing.

However, I wonder if the real problem is that the output window
is a sibling of the redirected widnows, rather than the parent.
It seems to me that the cleanest architecture is one where the
output window is the parent of all the redirected windows.

What if windows were *not* clipped by redirected children (atleast
for manual redirection)?  Then, in the LG example, LG could either
use the root window as the output window (or, if rendering to
the root window is not an option for the reasons Deron mentioned
elsewhere in this thread, then create a fullscreen child of the
root window for rendering the output, and then reparent all other
windows under the output window).  If ClipByChildren rendering
to the parent is not clipped by redirected children, then OpenGL
rendering won't be clipped either.

I may be misunderstanding this, but I believe the above would
solve both the problem of the output window getting clipped, and
the problem of the output window accidentally getting redirected.

As a side benefit, other composite managers won't need to use
IncludeInferiors, which feels a little kludgy to me.

A variation on the above that might provide more flexibility is to
turn this decision of whether redirected children clip the parent
into an attribute that is specified at redirection time.

Anyway, my $.02

Thanks,
- Andy



On Fri, 6 Jan 2006, Keith Packard wrote:

> On Fri, 2006-01-06 at 16:30 -0800, Deron Johnson wrote:
> 
> > Moving the highest normal window to the topmost stack and moving the
> > lowest topmost window to the normal stack is tantamount to no stack
> > change at all. It's effectively a no-op, as far as normal standard X11
> > events are concerned. So I would suggest that these operations generate
> > no events at all.
> 
> I'm thinking that topmost windows won't be visible under QueryTree;
> otherwise window managers will attempt to manage them, and applications
> may reasonably be confused when RaiseWindow doesn't result in a window
> at the visible top of the stack.
> 
> With this semantic, we need some idea of what events will be generated
> when a window moves between these two groups; otherwise windows will
> appear and disappear without any notification.
> 
> > > Another question is whether it is valid and useful to allow
> > > non-overrideRedirect topmost windows. I suggest that we should allow
> > > this, but that we note that existing window managers are unlikely to do
> > > anything useful with these windows, and in fact without knowledge that
> > > the window manager will work correctly, applications are probably better
> > > off not creating such windows.
> > 
> > This seems reasonable to me. (See the notes for rules #3 and #4 above).
> 
> yeah, I like the 'your wm will likely not handle this' rule; it allows
> us to provide wm rules in the future if it makes sense.
> 
> -keith
> 
>