I feel configure events and requests are messed up

[Bill Spitzak]

I believe that unless the client has final say, and an unambiguous 
method to force a window to any dimension it wants, then Wayland is a 
failure. Please do not copy the asynchronous window management of X11!

Here is what I see:

1. There is a client->compositor call that says "resize this window to 
here". It is obeyed UNCONDITIONALLY and the window ends up EXACTLY the 
requested size. An actual resize of a window to a new size is done by a 
client doing the following steps:

   a. The client allocates an image buffer of the new size.

   b. The client draws the resized image into the buffer (including 
window borders)

   c. The client tells the compositor about the new buffer and also 
about the new resize request. Possibly this is merged into a single call 
or Wayland does something to force atomic actions.

   d. The result is an INSTANTANEOUS (ie during the vertical retrace)
change of the composited on-screen image from showing the old image at 
the old size to the new image at the new size. THE USER NEVER NEVER 
NEVER SEES A PARTIAL UPDATE! All pixels that were not in the window and 
are now in the window change exactly once, from whatever they were 
displaying before to the new resized image. There is no way to do this 
unless the image is rendered already, no amount of "speed" can fix this, 
you must have the image before the resize. Every pixel that was in the 
window and now is not changes exactly once as well (this seems to be 
less of a problem with X11 and Windows compositing).

2. There is a compostitor->client call that says "the user is trying to 
resize the window to be like this". The compositor assumes the client 
will respond with the above resize call, or something similar (ie the 
client can fix the call to round the call the increments and aspect 
ratios and any other rules it wants).

3. There is another client->compositor call that says "the user is 
dragging the mouse and I have decided it is a window move/resize and I 
want the compositor to take over and handle it". This allows the clients 
to intercept every single possible click in the window without the 
hideous complexity that is in X11 and Windows. This is because they 
simply get every event first and can decide what to do. However this 
allows the compositor to implement window snapping and preview, rather 
than the clients having to do it. This gets I think about 100% of the 
advantages of the X11 window managers.

Please note that any scheme that does not allow the client to completely 
render the new resized image before the window is resized is not 
acceptable and violates Wayland's design requirements for flicker-free 
update. Stop suggesting such things, PLEASE!

It looks like both the resize request and the compositor message can 
have an xywh rectangle and four "edge" flags, and possibly a "title" 
flags. The Wayland API xml document shows the edge flags but I have not 
examined what they do, but as I see it they indicate whether a window 
border is wanted on that edge. The "title" flag I would add to indicate 
if a title is wanted (Windows-style maximize would turn off all the 
edges but not the title, while full-screen would turn off the title too. 
Tiling window managers would use these flags quite a bit. Clients would 
be assumed to leave the window edges without borders at the requested 
locations.)