Finishing Composite to handle transformed windows

[Deron Johnson]

Keith Packard wrote On 01/06/06 14:24,:

> If we're really going to support this in earnest, I suggest that all of
> the usual configuration functions should work as if there were two
> separate stacks of windows, the 'normal' and the 'topmost', so you
> should be able to raise or lower topmost windows within the topmost set
> using the normal set of operations. When a window is moved from 'normal'
> to 'topmost', it should be placed at the bottom (?) of the topmost set.
> Similarly, when moved from topmost to normal, it should appear on the
> top of the normal windows.

Yes. The concept of a "topmost window stack" seems more general and it
defines reasonable semantics for multiple top-most windows.

Here are some suggested rules:

1. Windows in the topmost window stack always are displayed above
   windows in the normal stack.

2. A TBD request is called to move a window from one stack to another.

3. The ConfigureWindow protocol request only restacks the given window
   within its current stack. Expose and ConfigureNotify events are sent
   as usual. If the override-redirect attribute is False and some other
   client has selected SubstructureRedirectMask on the parent, the X
   server generates a ConfigureRequest event to that client and no
   restacking occurs.

   Note: not all window managers may know how to handle properly handle
   a ConfigureRequest event that is generated for a restack operation
   within the topmost window stack, so it is recommended that windows
   in this stack always have their override redirect attribute set
   to True.

4. The CirculateWindow protocol request only restacks the given window
   within its current stack. Expose and CirculateNotify events are
   sent as usual. If the override-redirect attribute is False and some
   other client has selected SubstructureRedirectMask on the parent,
   the X server generates a CirculateRequest event to that client and no
   restacking occurs.

   Note: not all window managers may know how to handle properly handle
   a CirculateRequest event that is generated for a restack operation
   within the topmost window stack, so it is recommended that windows
   in this stack always have their override redirect attribute set
   to True.

5. If the highest window in the normal window stack is moved to the
   topmost stack, no events are generated.

6. If the lowest window in the topmost stack is moved to the normal
   stack, no events are generated.

> I don't know precisely what events should be triggered when windows move
> between topmost and normal stacks; we can either ignore the problem and
> generate no events, we can pretend they're getting reparented, or we can
> pretend they're getting destroyed/recreated. (See rules #5 and #6 above).

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.

> 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).