Wayland Window Management Proposal

[Bill Spitzak]

Kristian Høgsberg wrote:

> I had a quick read through this and there is a lot of overlap with how
> Wayland works today... are you proposing to change how Wayland works
> or are you not familiar with what's already in place?

A lot of this is based on my understanding of how Wayland works, and 
from the XML description of the protocol. I tried to document what I 
believe but has never been really stated for Wayland.

Main addition I made without previous knowledge was the parent and the 
task objects (so that a task manager client can figure out what to 
display), and the window management events (rather than try to guess 
what happens based on movements of the windows, which seemed to be what 
was planned for Wayland).

> Anyway, for decorations and tiling window managers, bear in mind that
> CSD is not about insisting that clients always draws decorations, but
> about making clients draw the decorations *when* decorations are
> desired.

I mostly see CSD as meaning "the server never draws any kind of 
decorations". I agree it is a good idea for the server to be able to 
tell the client to not to draw decorations (done in this proposal with 
the resize events having 4 flags to turn the edges on/off and another 
flag for the title bar). But the server must *never* draw them, because 
that would require the api by which the client describes the decorations 
to the server, which is the source of the complexity and interface 
lock-in that we have in X and Windows.

I also believe window actions such as move, map, and raise must be 
client-side. Otherwise correct movement of child windows will require an 
equally-complex api to send this information to the server. So I really 
tried to make it clear how I see this working. Proper child windows 
where the app has complete control could be a major user interface 
advantage over Windows and OS/X.