On Mon, 4 Apr 2016 12:05:05 -0700 Bill Spitzak <spit...@gmail.com> said:
> 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. why? apps rarely change min/max size and if they do they invariably also want to resize and re-render. what is the problem with changing min and/or max size at the same time? it's not like its a huge cost considering everything else... > 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. the logic behind a max size hint is not to have the apps switch to it but to know in advance what it might be so you can lay out windows nicely - very useful for tiling wm's. > On Mon, Apr 4, 2016 at 11:15 AM, Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > > > > > On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan <ofour...@redhat.com> > > wrote: > > > >> Hi Mike, > >> > >> > 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? > >> > >> 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). > >> > > > > 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. > > > > > >> > >> > 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! > >> > > >> > 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? > >> > >> 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 :-) > >> > >> Cheers, > >> Olivier > >> > > > > 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. > > > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel