Sub-surface protocol

[Pekka Paalanen]

On Thu, 13 Dec 2012 14:47:57 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> FLOATING WINDOWS:
> 
> PLEASE consider reusing this code for "floating windows". THEY ARE THE 
> SAME THING!!! The only difference is that the compositor can insert 
> other surfaces between floating children and the parent.
> 
> This would allow all work done to make subsurfaces not blink and to move 
> in lock-step also be used for floating windows, which would address a 
> deficiency in all existing window systems. It will also force the 
> floating window api to allow the client to be in final control of the 
> stacking order, a deficiency in all existing window systems.
> 
> Conversely floating windows have a lot of stuff figured out for focus 
> and event handling, like grabs, and cooperation between tasks and 
> threads. All of this is needed for subwindows so it makes sense to reuse it.

No, sub-surfaces are not sub-windows. A set of sub-surfaces forms a
single solid window. Surface management belongs to the core, window
management to the shell.

At first I was thinking that I could implement tooltips as
sub-surfaces since they do not need any shell features, but then I
realized that even that is nonsense, as it would break the _window_
geometry.

> CLIP:
> 
> Main windows need clip as well. This is so they can draw edge 
> decorations that are clipped off when the window is maximized, rather 
> than having to alter their drawings depending on maximization.
> 
> More important surfaces should be able to inverse-clip (the clip is 
> bigger than the image) for cases where the shell api needs a particular 
> size but the client knows that a portion is not visible. We need this to 
> clip off any number of edges less than 4 (for maximize 
> horizontal/vertical), and to allow subwindows to be used to add the 
> borders to a main window that is actually smaller than it tells the shell.

I don't think so.


Thanks,
pq