<div dir="ltr"><div>Hm, you raise some interesting points. However, I think your argument is somewhat misled by your claim that "this case is unique". If there is an application which does not want to be larger than a certain size, why could there not also be an application which does not want to be smaller than a certain size?</div><div><br></div><div>It seems like continuing to add size hints based on this logic is almost guaranteed, especially if you then add in the point of tiling policies--surely handling tiling would be made even easier by adding min/step/aspect sizes!</div><div><br></div><div>To me, xdg-shell should just be a bare minimum of things required to implement a UI with Wayland. Perhaps if there's a real need for size hints (which I really hope there isn't, since it made X11 window sizing very annoying) then there should be a separate size hints protocol where all of this can be implemented?</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 12:55 PM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mike,<br>
<br>
Thanks for starting the discussion! :)<br>
<br>
----- Original Message -----<br>
> Just to play devil's advocate, do we really want to start getting into size<br>
> hint type stuff? After this will be min size, then step size, then aspect,<br>
> ...<br>
<br>
I think these are different issues.<br>
<br>
min size, step size, aspect are client specific, you usually don't find a compositor that lets you non-interactively resize a window to arbitrary size, the only exception for that is maximize and fullscreen.<br>
<br>
This is really needed solely to let the compositor know what would be the largest acceptable size for the given surface (as for interactive resize, the client has the final word so we do have size increment, min size, even aspect ratio covered).<br>
<br>
I have been rightfully pointed out that the gnome bug where I started from is actually an application bug, ie xdg-shell clearly states that if the surface is maximized or fullscreen, the window geometry specified in the configure event must be obeyed by the client, so I have attached a patch for gtk+ to address that.<br>
<br>
Yet, I think a way for the client to let the compositor know that its surface should not be resized to anything bigger that a given size would help improve the user experience, not all windows look good when resized to arbitrary large sizes (they can doesn't necessarily mean they should).<br>
<br>
Beside, as opposed to what was stated on irc, I think it would also help with tiling window managers as well, to base their euristic on the largest optimal size for some windows.<br>
<br>
Cheers,<br>
Olivier<br>
</blockquote></div>