Wayland Window Management Proposal

[Russell Shaw]

On 19/05/11 04:17, Bill Spitzak wrote:
> 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.

In case of mouse-click events in the titlebar for a resize, if the client
then tells the window server to resize the window, then no echo event is
needed because the server now knows the client is still active. If the
client doesn't want to resize, then it could send an echo, or else just
request a resize using the current size.