[PATCH] xdg-shell: add set_max_size request

[Bill Spitzak]

I think sending stepping size or aspect is not needed, but steps will 
work only if the client can add a constant. Ie the width can be n*A+B 
where A and B are specified by the client. The X11 version did not allow 
a client to add a border that was not a multiple of the steps thick, 
which made it pretty much impossible.

Aspect also needs the ability for the client to add a constant so a 
frame can be put around the fixed-content area.

Both of these I think are better handled by the client doing the resize 
however, so only min/max should be sent.

On 04/04/2016 07:20 PM, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 04 Apr 2016 19:44:58 +0000 "Jasper St. Pierre" <jstpierre at mecheye.net>
> said:
>
>> I think min/max hints are acceptable in xdg-shell.
>
> i agree. they are realistic things a apps have as constraints on their content.
> knowing in advance what those constraints might be can make life for a
> compositor much easier.
>
> eg. if you set max size and its < screen size (or whatever size a maximized
> window might be in the wm) the em/compositor can disable the maximize action
> entirely.
>
> already pointed out - tiling wms can alter their layout policy for content eg
> placing content that has a small max height along the bottom or top of your
> screen.
>
> yes - asking for max size opens up min size too.
>
> i would argue size stepping is kind of needed too - the case of a tiling wm
> with eg:
>
> +---+---+
> | 1 | 2 |
> +---+---+
> | 3 | 4 |
> +---+---+
>
> if all the windows are terminals whose content is only correct at "size units"
> (because otherwise the terminal pads out N pixels without expanding the
> terminal grid there just wasting space), then when resizing the dividers across
> the middle of the screen -0 dragging them up/down or left/right a wm might want
> to limit the sizing to steps of N pixels assuming all clients involved share a
> common size step (the implied default is 1 pixel). without this hint a wm is
> unable to do anything sensible here.
>
> i am not saying the wm MUST follow the hints. there are impossible cases. one
> window (1) uses size step 10x10, and (2) uses 9x9... there are very few points
> where they "agree". (at 0x0 +base, 90x90 + base , 180x180 + base etc.) so as a
> wm i would assume it would only follow stepping if all steps are multiples of
> each other eg 3x3, 6x6, 9x9 or 2x2, 4x4, 6x6, 8x8 etc. ... (or are the same).
> clients still have to deal with arbitrary sizing in some sensible way.
>
> aspect hints tho are rather painful. they assume a single piece of content that
> has to retain aspect (eg 1 movie). i'd personally not want to go this far. :)
>
>> On Mon, Apr 4, 2016, 12:33 PM Mike Blumenkrantz <
>> michael.blumenkrantz at gmail.com> wrote:
>>
>>> On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan <ofourdan at redhat.com>
>>> wrote:
>>>
>>>>
>>>> Hi Mike,
>>>>
>>>> ----- Original Message -----
>>>>> [...]
>>>>>
>>>>> 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.
>>>>
>>>> My turn to play the Devil's advocate then :-)
>>>>
>>>> And even if we end with more hints eventually, what is wrong with that?
>>>>
>>>> I reckon if we had hints in X11, it's also because people have had a need
>>>> for such a mechanism...
>>>>
>>>> Cheers,
>>>> Olivier
>>>>
>>>
>>> Sure, and as I said, I have no issues with that if a separate (optional)
>>> protocol  is created for it. I just don't think that the best place for it
>>> is in xdg-shell, which is supposed to be just a small core set of features
>>> that are absolutely required in order to create a usable desktop
>>> environment.
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>
>