Wayland Window Management Proposal
spitzak at gmail.com
Wed May 18 11:17:14 PDT 2011
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.
More information about the wayland-devel