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

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz <zmike at osg.samsung.com>

On Wed, Apr 13, 2016 at 2:18 PM Olivier Fourdan <ofourdan at redhat.com> wrote:

> Just a quick note, not that it matters much, but this should have been v7,
> not v6, I got confused with the numbering of iterations :)
>
> Cheers,
> Olivier
>
> ----- Original Message -----
> > Some application may wish to restrict their window in size, but
> > xdg-shell has no mechanism for the client to specify a maximum or
> > minimum size.
> >
> > As a result, the compositor may try to maximize or fullscreen a window
> > while the client would not allow for the requested size.
> >
> > Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> > the client can tell the compositor what would be its smallest/largest
> > acceptable size, and that the compositor can decide if maximize or
> > fullscreen is achievable, draw an accurate animation, etc.
> >
> > Signed-off-by: Olivier Fourdan <ofourdan at redhat.com>
> > Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> > ---
> >  v2: Rename the request to "set_preferred_max_size",
> >      add "set_preferred_min_size" as well
> >  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
> >      Rephrase description to clarify the unscaled size and using 0 to
> >      reset back the preferred size to an unspecified state
> >  v4: Patch the correct xml file (v6, not v5 <facepalm>)
> >      Fix multiple mismatch of min/max in the description
> >      Remove mention of "unscaled", specify window geometry coordinates
> >      and refer to set_window_geometry.
> >  v5: Fix typos and remove "preferred" from the name and description as
> >      requested by several people on the ML and irc.
> >  v6: Specify the requests are double-buffered and require a commit,
> >      rephrase the values never set as suggested by Jasper, state
> >      that min > max is an invalid state and result in a protocol error
> >      as suggested by Bill, Yong and Jonas.
> >      Specify that width/height values must be greater than or equal to
> >      zero as discussed with Mike.
> >
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74
> >  ++++++++++++++++++++++++++++
> >  1 file changed, 74 insertions(+)
> >
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 3fc7d42..eba31ce 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -489,6 +489,80 @@
> >        <arg name="states" type="array"/>
> >      </event>
> >
> > +    <request name="set_max_size">
> > +      <description summary="set the maximum size">
> > +     Set a maximum size for the window.
> > +
> > +     The client can specify a maximum size so that the compositor does
> > +     not try to configure the window beyond this size.
> > +
> > +     The width and height arguments are in window geometry coordinates.
> > +     See set_window_geometry.
> > +
> > +     Values set in this way are double-buffered. They will get applied
> > +     on the next commit.
> > +
> > +     The compositor can use this information to allow or disallow
> > +     different states like maximize or fullscreen and draw accurate
> > +     animations.
> > +
> > +     Similarly, a tiling window manager may use this information to
> > +     place and resize client windows in a more effective way.
> > +
> > +     If never set, or a value of zero in the request, means that the
> > +     client has no expected maximum size in the given dimension.
> > +     As a result, a client wishing to reset the maximum size
> > +     to an unspecified state can use zero for width and height in the
> > +     request.
> > +
> > +     Requesting a maximum size to be smaller than the minimum size of
> > +     a surface is illegal and will result in a protocol error.
> > +
> > +     The width and height must be greater than or equal to zero. Using
> > +     strictly negative values for width and height will result in a
> > +     protocol error.
> > +      </description>
> > +      <arg name="width" type="int"/>
> > +      <arg name="height" type="int"/>
> > +    </request>
> > +
> > +    <request name="set_min_size">
> > +      <description summary="set the minimum size">
> > +     Set a minimum size for the window.
> > +
> > +     The client can specify a minimum size so that the compositor does
> > +     not try to configure the window below this size.
> > +
> > +     The width and height arguments are in window geometry coordinates.
> > +     See set_window_geometry.
> > +
> > +     Values set in this way are double-buffered. They will get applied
> > +     on the next commit.
> > +
> > +     The compositor can use this information to allow or disallow
> > +     different states like maximize or fullscreen and draw accurate
> > +     animations.
> > +
> > +     Similarly, a tiling window manager may use this information to
> > +     place and resize client windows in a more effective way.
> > +
> > +     If never set, or a value of zero in the request, means that the
> > +     client has no expected minimum size in the given dimension.
> > +     As a result, a client wishing to reset the minimum size
> > +     to an unspecified state can use zero for width and height in the
> > +     request.
> > +
> > +     Requesting a minimum size to be larger than the maximum size of
> > +     a surface is illegal and will result in a protocol error.
> > +
> > +     The width and height must be greater than or equal to zero. Using
> > +     strictly negative values for width and height will result in a
> > +     protocol error.
> > +      </description>
> > +      <arg name="width" type="int"/>
> > +      <arg name="height" type="int"/>
> > +    </request>
> > +
> >      <request name="set_maximized">
> >        <description summary="maximize the window">
> >       Maximize the surface.
> > --
> > 2.5.5
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160413/cfdbb6d2/attachment.html>