[PATCH] Introduce set_size_hints xdg_surface request.

[Bill Spitzak]

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
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>