[PATCH] xdg-shell: add set_max_size request

[Carsten Haitzler (The Rasterman)]

On Mon, 4 Apr 2016 12:05:05 -0700 Bill Spitzak <spitzak at 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.blumenkrantz at gmail.com> wrote:
> 
> >
> >
> > On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan <ofourdan at 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 at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> >


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com