Re: [PATCH] xdg-shell: add set_max_size request
On Mon, 4 Apr 2016 12:05:05 -0700 Bill Spitzaksaid: > 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
On Mon, 4 Apr 2016 22:40:10 -0700 Bill Spitzaksaid: > 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
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
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
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
"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 Fourdanwrote: > 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
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
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
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
On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdanwrote: > > 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
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
On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdanwrote: > 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
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
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 Fourdanwrote: > 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
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
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 Fourdanwrote: > 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
[PATCH] xdg-shell: add set_max_size request
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 FourdanBugzilla: 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