Re: [PATCH] xdg-shell: add set_max_size request

[The Rasterman]

On Mon, 4 Apr 2016 12:05:05 -0700 Bill Spitzak  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 
> > 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

Re: [PATCH] xdg-shell: add set_max_size request

[The Rasterman]

On Mon, 4 Apr 2016 22:40:10 -0700 Bill Spitzak  said:

> 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.

yes the x11 version DId allow this. that's what base size was. stepping was to
be done as base size + integer * step. read icccm.

of course when i mention stepping i do mean base + size in integer multiples
of a step as that is what icccm did and what existing apps have come to support
and use and... what is necessary.

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

aspect does this too. in fact it was min and max aspect  accounting for
base size too:

http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html

x11 did get this right. aspect was really minimally useful. stepping was useful
for just about every terminal and min/max have been widely used by apps.

> 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 + "Jasper St. Pierre"
> >  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.blumenkra...@gmail.com> wrote:
> >>
> >>> On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan 
> >>> 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@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >>>
> >
> >
> 
> ___
> wayland-devel mailing list
> 

Re: [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.blumenkra...@gmail.com> wrote:

>
>
> On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan 
> 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
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [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 + "Jasper St. Pierre" 
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.blumenkra...@gmail.com> wrote:


On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan 
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel






___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Olivier Fourdan]

Hi Jasper,

- Original Message -
> "hint" just means "don't bother setting this flag, since it won't do
> anything".
> 
> If we want min/max size rules, I want them to be enforced. Compositors
> SHOULD NOT attempt to configure windows above or below the requested
> size.

Right, so it gets slightly more complicated because I heard the exact opposite 
from other people yesterday on irc, basically, this should not be enforced and 
we should not use "hint" in the name/description because it is a dirty word 
nowadays.

FWIW, I am in favor of not enforcing the min/max size, it may be used as an 
indication (see, I didn't write hint!) for WM/compositors, but they are free to 
just ignore them (after all, this indication is there for the compositors, not 
the clients), and the the size set in the configure event following a 
maximize/fullscreen are still mandatory to obey (as it i now).

/me puts my updated patch on hold, then

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Jasper St. Pierre]

"hint" just means "don't bother setting this flag, since it won't do anything".

If we want min/max size rules, I want them to be enforced. Compositors
SHOULD NOT attempt to configure windows above or below the requested
size.

On Mon, Apr 4, 2016 at 11:58 PM, Olivier Fourdan  wrote:
> Hi all,
>
> - Original Message -
>> On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre"
>> 
>> 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.
>
> So, it seems max/min "hints" can be desirable from a window/compositor 
> manager point of view, whereas things like aspect ratio, size steppings, etc. 
> aren't
>
> I'll send an updated patch to:
>
>  - Reword the description and request name to make it clearer that it really 
> is a preference and not a rule (Quentin mentioned that on irc yesterday), 
> without using the word "hint" :)
>  - add a similar "preferable min size" request
>
> Then we can continue discussing from there.
>
> Cheers,
> Olivier
>



-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Olivier Fourdan]

Hi all,

- Original Message -
> On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre"
> 
> 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.

So, it seems max/min "hints" can be desirable from a window/compositor manager 
point of view, whereas things like aspect ratio, size steppings, etc. aren't

I'll send an updated patch to:

 - Reword the description and request name to make it clearer that it really is 
a preference and not a rule (Quentin mentioned that on irc yesterday), without 
using the word "hint" :)
 - add a similar "preferable min size" request

Then we can continue discussing from there.

Cheers,
Olivier
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[The Rasterman]

On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre" 
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.blumenkra...@gmail.com> wrote:
> 
> > On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan 
> > 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@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

Re: [PATCH] xdg-shell: add set_max_size request

[Jasper St. Pierre]

I think min/max hints are acceptable in xdg-shell.

On Mon, Apr 4, 2016, 12:33 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan 
> 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan  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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Olivier Fourdan]

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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan  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

Re: [PATCH] xdg-shell: add set_max_size request

[Olivier Fourdan]

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).
 
> 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

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 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?

On Mon, Apr 4, 2016 at 12:55 PM Olivier Fourdan  wrote:

> Hi Mike,
>
> Thanks for starting the discussion! :)
>
> - Original Message -
> > Just to play devil's advocate, do we really want to start getting into
> size
> > hint type stuff? After this will be min size, then step size, then
> aspect,
> > ...
>
> I think these are different issues.
>
> min size, step size, aspect are client specific, you usually don't find a
> compositor that lets you non-interactively resize a window to arbitrary
> size, the only exception for that is maximize and fullscreen.
>
> This is really needed solely to let the compositor know what would be the
> largest acceptable size for the given surface (as for interactive resize,
> the client has the final word so we do have size increment, min size, even
> aspect ratio covered).
>
> I have been rightfully pointed out that the gnome bug where I started from
> is actually an application bug, ie xdg-shell clearly states that if the
> surface is maximized or fullscreen, the window geometry specified in the
> configure event must be obeyed by the client, so I have attached a patch
> for gtk+ to address that.
>
> Yet, I think a way for the client to let the compositor know that its
> surface should not be resized to anything bigger that a given size would
> help improve the user experience, not all windows look good when resized to
> arbitrary large sizes (they can doesn't necessarily mean they should).
>
> Beside, as opposed to what was stated on irc, I think it would also help
> with tiling window managers as well, to base their euristic on the largest
> optimal size for some windows.
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Olivier Fourdan]

Hi Mike,

Thanks for starting the discussion! :)

- Original Message -
> Just to play devil's advocate, do we really want to start getting into size
> hint type stuff? After this will be min size, then step size, then aspect,
> ...

I think these are different issues.

min size, step size, aspect are client specific, you usually don't find a 
compositor that lets you non-interactively resize a window to arbitrary size, 
the only exception for that is maximize and fullscreen.

This is really needed solely to let the compositor know what would be the 
largest acceptable size for the given surface (as for interactive resize, the 
client has the final word so we do have size increment, min size, even aspect 
ratio covered).

I have been rightfully pointed out that the gnome bug where I started from is 
actually an application bug, ie xdg-shell clearly states that if the surface is 
maximized or fullscreen, the window geometry specified in the configure event 
must be obeyed by the client, so I have attached a patch for gtk+ to address 
that.

Yet, I think a way for the client to let the compositor know that its surface 
should not be resized to anything bigger that a given size would help improve 
the user experience, not all windows look good when resized to arbitrary large 
sizes (they can doesn't necessarily mean they should).

Beside, as opposed to what was stated on irc, I think it would also help with 
tiling window managers as well, to base their euristic on the largest optimal 
size for some windows.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

Just to play devil's advocate, do we really want to start getting into size
hint type stuff? After this will be min size, then step size, then aspect,
...

On Mon, Apr 4, 2016 at 5:14 AM Olivier Fourdan  wrote:

> Some application may wish to restrict their window in size, but
> xdg-shell has no mecanism for the client to advertise such a maximimum
> size.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the client would not allow for the requested size.
>
> Add a new request "set_max_size" to xdg-shell so that the client can
> tell the compositor which would be its largest acceptable size, so that
> the compositor can decide if maximize or fullscreen makes sense, draw
> an accurate animation, etc.
>
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v5.xml | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> index 542491f..e9e0f1d 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> @@ -462,6 +462,26 @@
>
>  
>
> +
> +  
> +The client can set a maximum size to tell the compositor what
> would
> +be the largest acceptable size of a surface.
> +
> +The compositor can use this information to allow or disallow the
> +maximized or fullscreen state depending on the actual output size
> +for example, or draw a more accurate animation when transitionning
> +states.
> +
> +If never set, the size is not limited by the client.
> +
> +A value of zero for either width, height or both means that the
> +size is not limited for the given dimension.
> +  
> +  
> +  
> +
> +
> +
>  
>
>  Maximize the surface.
> --
> 2.5.5
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel