Wayland Window Management Proposal

[Michal Suchanek]

2011/5/11 Bill Spitzak <spitzak at gmail.com>:
> 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 don't think you need an API for that. Either the application accepts
what the server draws or it wants to draw its own.
So it's like
 - application wants its own borders (bool)
 - server takes care of borders (bool)
two bits.

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

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

Maybe in an ideal world each application would be split into two (or
more) processes, one taking care of the UI interaction and the
other(s) doing the actual work so that the UI is always responsive.

However, this is not the case and for moves and resizes to work
properly they have to be done in the window manager. For many
applications responding to UI events is rather low priority and when
they are busy doing something the UI is not going to be handled.

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.

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.

Thanks

Michal