Wayland Window Management Proposal

[Michal Suchanek]

On 11 May 2011 20:25, Bill Spitzak <spitzak at gmail.com> wrote:
> 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.

Then rewrite all the applications. When you are done with that we can
get rid of server side resizes.

>
>> 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.

Oh, come on, can't you came up with some real excuse?

With all the various effects the compositors implement have you never
heard of fade-in?


Thanks

Michal