[PATCH] Introduce set_size_hints xdg_surface request.

[Pekka Paalanen]

On Tue,  5 Aug 2014 22:07:39 +0300
Jari Vetoniemi <mailroxas at gmail.com> wrote:

> Rationale for this patch is to provide way for applications that can't go below/above
> certain bounds to inform compositor about it.
> 
> More feedback is needed. For example are maximimum size useful for any
> particular application?
> ---
>  protocol/xdg-shell.xml | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)

Hi,

I have a few technical questions.

> 
> diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> index bd36231..6e48ae6 100644
> --- a/protocol/xdg-shell.xml
> +++ b/protocol/xdg-shell.xml
> @@ -235,6 +235,24 @@
>        <arg name="edges" type="uint" summary="which edge or corner is being dragged"/>
>      </request>
>  
> +    <request name="set_size_hints">
> +      <description summary="provide surface size hints">
> +        Server should use these hints to figure out how much surface may be,
> +        resized so that the content still remains sane. Hints will remain
> +        the same until set_size_hints is requested again.
> +
> +        Hints set this way are double buffered. They will get applied on
> +        the next commit.
> +
> +        These hints should take effect regardless of the surface state.
> +        A size less than zero unsets the hint.

What is the default value of these hints?

When is the client expected to send this? Can this be sent before
the window gets mapped? After the window was unmapped?

How does this interact with the protocol sequence to decide the initial
size of a window before it gets mapped?

Making surface state double-buffered is desired for all state that
immediately affects the surface's presentation. However, these are
hints and do not change how the surface is presented; they change what
sizes the compositor may ask for in configure events. It that sense, it
is not necessary to make this state double-buffered, and I think not
double-buffering (not demanding a commit) will make it easier to use
and also to define how it works with the initial size negotiation.


Thanks,
pq

> +      </description>
> +      <arg name="min_width" type="int" summary="minimum width of the surface"/>
> +      <arg name="min_height" type="int" summary="minimum height of the surface"/>
> +      <arg name="max_width" type="int" summary="maximum width of the surface"/>
> +      <arg name="max_height" type="int" summary="maximum height of the surface"/>
> +    </request>
> +
>      <enum name="state">
>        <description summary="types of state on the surface">
>          The different state values used on the surface. This is designed for