Wayland Window Management Proposal

[Bill Spitzak]

Michal Suchanek wrote:

> In the case of a resize event the response includes submitting a
> buffer containing resized window content to the compositor.
> 
> The compositor requires this new resized content to draw the window so
> it cannot be avoided.

I think the concern was when a client decided that the current window 
size is correct. This can happen if the window is not resizable, or size 
limits or increments or anything else cause the requested size to be 
rounded to the same size as it is currently. I think there is also a 
problem in that the compositor cannot be absolutely certain that a given 
resize is in response to a resize request.

What I was proposing is that there is a clear "echo" of all events back 
to the compositor, so the compositor can know that event has been 
handled by the client. This would be sent after the resizing, or sent by 
itself if the client decided not to resize.

Echos can be consolidated. An echo saying a given event was handled 
would also indicate that all earlier events were handled. This is 
necessary to make it easier to write clients that want to consolidate 
incoming events, for instance to only handle the last of a whole string 
of resize requests.

The echo can also indicate that the client explicitly did not handle an 
event and it wants the compoitor to do so. This can allow reuse of the 
compositor locked-client window handling by normal clients. It also 
would allow clients to indicate ignored keystrokes so the compositor can 
  do something with them, allowing a lot more global shortcut possibilities.