I can see a minimum size being useful for this, but not a maximum.
Compositors are allowed to request sizes smaller than this, and cannot
assume clients will not resize surfaces smaller than this. It is just
advisory for layout. Compositors could assume the initial size is the
minimum if it is never given.
A useful addition would be something to the configure event that says
whether the horizontal or vertical size is more important. Many clients
have a minimum in one dimension that depends on the other dimension
(imagine a filled paragraph of text, it gets taller as it gets
narrower). This relationship is much too complicated to communicate to
the compositor so it will have to be done with round trips, I don't
think round trips can be avoided. Dead clients are detectable with the
ping/pong api.
A tiling window manager would use the minimum size to decide the
thickness of a row or column of clients. It would then use a round trip
to get the actual size in the opposite direction. An extra round trip
would be needed for the last client in the row or column to make it fill
the hole. After that it should just clip or pad the surfaces to fit.
Until all the round trips are done the compositor continues to display
the previous display and does not release the previous buffers.
On 08/06/2014 01:42 AM, Jari Vetoniemi wrote:
This doesn't work in the case of tiling WMs which may want some up-front
information about window sizes so they can lay them out correctly.
Currently, we say that the maximize and fullscreen states are strictly
sized, and clients *must* submit window geometry that's equivalent to that,
so there needs to be some negotiation from the point of the client so it can
say that it won't render a buffer at a silly size.
Some tiling WMs may still need to force the client sizes on certain
layouts. However this is better than nothing, as the tiling wm
actually has clue when the client would be rendered incorrectly and
when not. This is also better as trying to workaround, by checking
whether client responded to your resize request or not and figuring
out the bounds yourself, as the client may not be responding for other
reasons.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
