Finishing Composite to handle transformed windows

[Deron Johnson]

Benjamin Herrenschmidt wrote On 01/06/06 17:06,:

> Why not arbitrary windows stacks then (with a depth) ? It would make
> things easier for a whole lot of things like:

The suggested rules I sent out are easily extendible to encompass the
notion of more than two stacks. But I'm not sure that this is the
right semantic. If we provide more than one "non-normal" stack then
we will need some sort of policy definitions for how clients use
these stacks, window managers will need to be changed, and the problem
starts to balloon.

>  - Those various "desklets" implementations that have been floating
> around which are basically about putting widgets in the root window.
> Those could become normal windows at a higher depth
> 
>  - Various "tooltips" and other "alerts" effects provided by some
> environments really want to float above all windows. That would be a
> layer above the normal one and below the "topmost"

How does a client decide into which stack they should place a window?
If they choose the highest level then they will start to punch holes
in things like LG and Keith's magnifier.

In X's original vision things like this were supposed to be handled
at the window manager. The problem is that most of the types of
windows we are discussing are override redirect windows so they are
unknown to the window manager.

One way to handle this is to make the mapping and configuration of
override redirect windows controllable by the window manager. I
actually prototyped this at one time but I encountered severe
problems. Many apps (like emacs and mozilla) assume that they
can blast rendering out to override redirect windows without
waiting for an expose event and changing the semantics to
allow WM control wreaks havoc with these apps.

So, in this conversation, we started out with the suggestion of
having a topmost window, but then realized that there would be
multiple topmost windows (because the screen saver is a topmost
window) and so then we generalized it into a topmost window
stack. Now the question is whether we should generalize it
one step further to become a stack of stacks. To me, this would
create more problems than it solves because then we would have
to define more policies in order to use this stack of stacks
effectively.