Wayland Window Management Proposal

[Bill Spitzak]

Michal Suchanek wrote:

> Moves and resizes implemented in the client can't work well.

Any resize solution that does not allow an atomic on-screen update of a 
window to it's new size, with the resized decorations and contents, is 
unacceptable. The whole point of Wayland is that the user NEVER sees a 
partially-updated window.

It is therefore impossible to finish a resize without waiting for the 
client to update the window contents. Since you have to wait for that, 
there is no reason the client can't also draw the decorations. I'm sorry 
if this makes writing clients harder. Deal with it.

> So the user initiated resizes should happen in the compositor which
> paints the current content in the window of the new size and can
> possibly mix in some haze to make it obvious that the window was not
> resized yet and later the application should update the content size
> to match the window size and move any toolbars appropriately.

That would look like crap. The window would blink rapidly between the 
"haze" and final version.

> The problem is with broken applications (such as gimp) that respond to
> a resize of their window with application-initiated resize of the same
> window leading to a resize loop in tiling WMs.

That is a problem with X design where they tried to override the actual 
call to resize the window. In wayland the "change the window size" and 
the "I want to change the window size" messages are distinct.