[PATCH v8 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Jonas Ådahl]

On Mon, Apr 18, 2016 at 10:53:42AM -0700, Bill Spitzak wrote:
> On Mon, Apr 18, 2016 at 12:19 AM, Olivier Fourdan <ofourdan at redhat.com>
> wrote:
> 
> >
> > +       The client should not rely on the compositor to obey the maximum
> > +       size. The compositor may decide to ignore the values set by the
> > +       client and request a larger size. In such a case, the client can
> > +       either adapt to the requested size or refuse to acknowledge the
> > +       configure event sent by the compositor. See xdg_surface.configure
> > +       and xdg_surface.ack_configure for details.
> >
> 
> The client is allowed to also select a different size, not just "refuse to
> acknowledge the configure event". This wording implies that if the client
> is smaller than it's maximum, and the compositor requests larger than the
> maximum, the only possible things a client can do is use the
> compositor-requested size, or leave the surface smaller than the maximum.
> Certainly resizing to the maximum is also allowed.
> 
> Real clients only "refuse to acknowledge the configure event" after they
> calculate the size they want and discover it is equal to the current size.
> This can happen for any configure event, there is nothing special about
> these out-of-range ones.
> 
> Better wording: "In such a case, the client can either adapt to the
> requested size or choose a different size (perhaps the maximum). See
> xdg_surface.configure for details."

All of that is not really related to these new requests. If
xdg_surface.configuration needs clarification, it can be done
separately.

> 
> +       Requesting a maximum size to be smaller than the minimum size of
> > +       a surface is illegal and will result in a protocol error.
> >
> 
> I think you have to add "when the commit request is sent". I still think
> the current wording does not make it clear that it can be temporarily
> incorrect and that clients do not have to remember the previous setting and
> reorder these requests to avoid the error.

I don't think its needed. It should be quite obvious that this is about
the requested state to be applied.


Jonas