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

[Olivier Fourdan]

Hi Bill,

> 
> > > It allows a client to say "I look best below this size, but if the
> > > compositor wants to fill a larger rectangle, I can draw something nicer
> > > than the compositor can do (the compositor can only pad or scale)".
> >
> > That's something different, isn't it? The compositor sending a configure
> > event and the size specified there must be obeyed by the client (as
> > specified in the spec for maximize and fullscreen state, but the point of
> > using min/max is precisely to let the compositor know that such states are
> > not desirable for that given surface).
> 
> Clients do not have to obey the requested size by the compositor.

The spec reads, for state maximized and fullscreen:

    <enum name="state">
      <description summary="types of state on the surface">
      [...]
      <entry name="maximized" value="1" summary="the surface is maximized">
        <description summary="the surface is maximized">
          The surface is maximized. The window geometry specified in the configure
          event must be obeyed by the client.
        </description>
      </entry>
      <entry name="fullscreen" value="2" summary="the surface is fullscreen">
        <description summary="the surface is fullscreen">
          The surface is fullscreen. The window geometry specified in the configure
          event must be obeyed by the client.
        </description>
      </entry>
      [...]
    </enum>

That's https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n343
 
> This is
> how min/max size was being done previously, and how size increments and
> aspect ratios and any other client restrictions on possible size are still
> being done now.

I know. So either the description above is incorrect, or I don't understand what "must be obeyed" means in this context.

BTW, that's precisely the patches I wrote for gtk+ for fullscreen and maximized, ignore the size increments and now max size when receiving a configure event with state maximized or fullscreen.

For reference, that was:

https://bugzilla.gnome.org/show_bug.cgi?id=751368

and now

https://bugzilla.gnome.org/show_bug.cgi?id=764413

> I don't think clients should have to obey fullscreen either, though I'm not
> sure what the documentation says. The compositor can just center the
> surface above black if the client does not resize it, this functionality is
> already supported.

Correct, for fullscreen, this is the case, this is where I think the spec gets a tad confusing imho:

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n508

    <request name="set_fullscreen">
      <description summary="set the window as fullscreen on a monitor">
        Make the surface fullscreen.

        You can specify an output that you would prefer to be fullscreen.
        If this value is NULL, it's up to the compositor to choose which
        display will be used to map this surface.

        If the surface doesn't cover the whole output, the compositor will
        position the surface in the center of the output and compensate with
        black borders filling the rest of the output.
      </description>
      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
    </request>

So the client must obey the window geometry specified in the configure event when the state is fullscreen, but the surface may not cover the whole output.

> [...]
> 
> > My point was more about the client itself setting min/max and then setting
> > a geometry that falls outside of the limits it sets itself, I reckon that
> > should be a protocol error, the client is sending incompatible requests to
> > the compositor.
> 
> 
> No this absolutely must not be a protocol error.
> 
> *maybe* it could be a protocol error to resize larger than the maximum of
> the current maximum size and the configure request that it is responding
> to, but this is going to lead to synchronization issues since there is no
> serial number indicating the configure request it is processing. And it may
> even have to add a good deal of fudge factor so a client can continue to
> round to size increments. So even this idea looks very difficult and
> pointless to handle.

Yes, I agree, the client can set a geometry following a configure request, and that must respect the window geometry specified by the states in the configure events, which must be obeyed:

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n450

    <request name="set_window_geometry">
      <description summary="set the new window geometry">
        The window geometry of a window is its "visible bounds" from the
        user's perspective. Client-side decorations often have invisible
        portions like drop-shadows which should be ignored for the
        purposes of aligning, placing and constraining windows.

        [...]

        If responding to a configure event, the window geometry in here
        must respect the sizing negotiations specified by the states in
        the configure event.

        [...]
      </description>

So I think we should clarify the "must be obeyed" part of the configure event when state is maximized or fullscreen.

Cheers,
Olivier