List of topmost window issues

[Deron Johnson]

I've compiled a list of all of the open issues I am aware of related to
topmost windows. I'd like to find out if there is a consensus on the
first issue, namely should we pursue the topmost window concept further?
Does anybody strongly disagree with this general approach. To me, it
has clean, well-defined semantics and solves many of my problems, so
I am all for it.

And, if you have any objections my position on the other issues, please
voice them too.


Top-Most Windows
================

Open Issues
-----------

+ Issue: Are topmost windows the right paradigm? Is there a better idea?

    Pros:
	Solves a lot of problems for LG
	Relatively easy to implement
        Already an established idea in Windows

    Cons:
        None (that I can think of)

    My position:
	I strongly believe that X should support this.

+ Issue: Should topmost windows be only override redirect, or should
         we allow non-override redirect topmost windows.

    Pros:
	More general.

    Cons:
	May require window manager changes to implement.

    My position:
        I recommend restricting topmost windows to be override
        redirect, and relax it down the road if we need to.

+ Issue: Should we special-case CompositeRedirectSubwindows to ignore
         topmost windows, or should we implement a separate mechanism
         for specifying that it ignore a specified window?

    Pros:
	Introduces less new API.

    Cons:
        Topmost windows seem like a separate idea from the composite
        ignoring. Forcing them to be linked together like this could
        restrict freedom later on.

    My position:
        I recommend the keeping the composite ignoring mechanism
        separate.


+ Issue: Should we introduce the concept of a topmost window stack?
  The semantics would be as follows:

	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.

    Pros:
	Well-defined semantics for multiple topmost windows.
        Deals with what to say about non-override redirect topmost windows

    Cons:
        Probably will take a bit more to implement, but not much.

    My position:
	I am in favor of this.

+ Issue: Is there a bit available in the window structure that we can steal,
         or do we need to allocate a new window private?