Window stacking

[Bill Spitzak]

dottomi at gmail.com wrote:

> Excuse me, I'm just a bystander, but is this list you speak of a list of
> all the windows registered by all of the connected clients?

Yes

> The main problem I have using GIMP is that when I focus a window, I
> don't want to focus on a /window/, I want to focus on an /application/.
> This means I want all of the application's windows to be moved to the
> top.

In my proposal this is done by the client (GIMP) raising all the windows 
in response to the compositor telling it to raise one of them. The 
compositor does not need to know anything about the fact that the 
windows are related.

There are also "invisible" windows. Their only purpose is to provide 
entries in a task-manager or panel type application. Attempts to raise 
these are also handled by the client. For the GIMP there may be a single 
"gimp" icon in the task manager. The fact that it raises all the image 
and toolbar windows is only known by GIMP.

  If there is a list with only the windows, it would require to move
> all of the windows one by one. You can also have a third-party window
> between your application's windows, and I think that's the part that
> should be avoided.
> 
>> 2. There is a *atomic* api by which a client can map, unmap, and
>> change the stacking order of it's own windows.
> 
> "Of it's own windows" in an absolute list, or in a client-only list?

It's own windows in an absolute list. This would be done by requesting 
that window a (belonging to the client) be placed above/below window b 
(which can be None or a client or other window). None is the most 
useful. Compositors could also provide place-holder invisible windows so 
a client can indicate what "layer" a window is in (compositors can also 
force windows to be in "layers" by not obeying the window stacking order).

> Personally, I'd want to have a client request for a "single window
> object", and for a "window group object". In the server there would be a
> single list containing both single window objects and window group
> objects. A window group is an object which is managed by the client
> (map, unmap, register, unregister, reordering - i.e. what you're talking
> about here) and the client can only operate on windows in its own group
> object.

The "window group" is what I was calling the invisible windows for the 
task managers. However the compositor does not have to know anything 
about the group, the client is supposed to respond to requests to raise 
the group by raising all the necessary windows.

> It makes things easier in the server to restack windows because
> you can move a whole group at once in the server-side list and you avoid
> having a client's window positioned between windows of another client,
> where the latter client does not want any third-party windows between.
> It also makes it impossible for a client to make changes to the absolute
> server-side list.

There will be a need to make a whole group of reorders "atomic". This 
will make it look to the user as though the whole group raised at once, 
and prevent other applications from inserting their windows between 
them. Also this is vital so that a video player can use a low-res YUV 
window below a higher-res "frame" with a transparent area, and the user 
never sees them come apart.