<div dir="ltr">I do not like clients having to update this value continuously as conditions change. I would prefer any kind of design where the calculation of the maximum size is deferred until it is actually used, ie at the point that the user does whatever action attemts to make the window larger.<div><div><br></div><div>Perhaps an event similar to fullscreen saying "make yourself the largest size you want" would work. I'm wondering if "maximize" can just be reused for this.<br></div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 11:15 AM, Mike Blumenkrantz <span dir="ltr"><<a href="mailto:michael.blumenkrantz@gmail.com" target="_blank">michael.blumenkrantz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com" target="_blank">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>
> Hm, you raise some interesting points. However, I think your argument is<br>
> somewhat misled by your claim that "this case is unique". If there is an<br>
> application which does not want to be larger than a certain size, why could<br>
> there not also be an application which does not want to be smaller than a<br>
> certain size?<br>
<br>
It's unique because switching to maximize/fullscreen is not an interactive resize, ie the client doesn't have its word on the state change that implies the resize, and is mandatory configure event, until it's set by the compositor (ie too late, the client must obey, period).<br></blockquote><div><br></div></span><div>Maximize can mean different things in different cases. For example, suppose a compositor has a maximize policy where it can "maximize" a window to take up the top-left 25% of the screen. This size could be too small for the application, yet it falls within your non-interactive resize case.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> It seems like continuing to add size hints based on this logic is almost<br>
> guaranteed, especially if you then add in the point of tiling<br>
> policies--surely handling tiling would be made even easier by adding<br>
> min/step/aspect sizes!<br>
><br>
> To me, xdg-shell should just be a bare minimum of things required to<br>
> implement a UI with Wayland. Perhaps if there's a real need for size hints<br>
> (which I really hope there isn't, since it made X11 window sizing very<br>
> annoying) then there should be a separate size hints protocol where all of<br>
> this can be implemented?<br>
<br>
One case where a compositor may need a min size hint is a tiling window/compositing manager, so it can base its heuristics on those hints from the clients to get the optimal window size for tiling, but I would let those who implement such a window/compositor manager advocate for that, it's not the specific case I'm interested in here :-)<br>
<br>
Cheers,<br>
Olivier<br></blockquote><div><br></div></span><div>Yes, I know you are not currently advocating for it, but you've proved my point--others will see this go in and then they will push for it. Adding any form of size hints is a slipper slope which leads to more size hints imo. </div></div></div>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br></div>