Finishing Composite to handle transformed windows

[Keith Packard]

On Fri, 2006-01-06 at 13:00 -0800, Deron Johnson wrote:

> One issue that you didn't mention is the stacking semantics of
> multiple topmost windows. One suggestion I have made is that
> the last mapped topmost window should be the highest in the
> stack. This means that MapWindow on a topmost window is
> equivalent to MapRaised. I'd like to hear what you think
> of this idea.

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.

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.

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.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060106/f27cccfa/attachment.pgp>