[PATCH] xdg-shell: add set_max_size request

[Bill Spitzak]

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.

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.


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160404/dc2ebdad/attachment.html>