Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Jonas Ådahl]

On Fri, Aug 12, 2016 at 12:19:20PM -0700, Bryce Harrington wrote:
> On Fri, Aug 12, 2016 at 12:44:49PM +0800, Jonas Ådahl wrote:
> > On Thu, Aug 11, 2016 at 09:35:57PM -0700, Bryce Harrington wrote:
> > > On Fri, Aug 12, 2016 at 11:56:13AM +0800, Jonas Ådahl wrote:
> > > > On Thu, Aug 11, 2016 at 08:49:01PM -0700, Bryce Harrington wrote:
> > > > > On Fri, Jul 29, 2016 at 12:04:55PM +0800, Jonas Ådahl wrote:
> > > > > > In order to get feedback of available space where a client can 
> > > > > > create
> > > > > > its popup, let it create requset that its popup rectangle being 
> > > > > > resized
> > > > > > would it not fit the within the work area. This adds two new 
> > > > > > constrain
> > > > > > adjustment values to the adjustment enum, and dimension parameters 
> > > > > > to
> > > > > > the xdg_popup.configure event.
> > > > > > 
> > > > > > The existing constrain adjustment actions take precedence, and 
> > > > > > resizing
> > > > > > will only be triggered if all other adjustments requested didn't 
> > > > > > manage
> > > > > > to make the popup rectangle fully visible.
> > > > > > 
> > > > > > Signed-off-by: Jonas Ådahl 
> > > > > > Acked-by: Quentin Glidic 
> > > > > > ---
> > > > > > 
> > > > > > Chances since v1: none
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> > > > > > +---
> > > > > >  1 file changed, 30 insertions(+), 10 deletions(-)
> > > > > > 
> > > > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > > > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > > index 2c8f636..ef45ff4 100644
> > > > > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > > @@ -249,6 +249,19 @@
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > +  
> > > > > > +   The constrain adjustment value define ways the compositor will 
> > > > > > adjust
> > > > > > +   the position of the surface, if the unadjusted position would 
> > > > > > result
> > > > > > +   in the surface being partly constrained.
> > > > > 
> > > > > "constraint adjustment" maybe?
> > > > 
> > > > Isn't 'constraint' the noun, and 'constrain' the verb? What I mean is
> > > > the adjustment done while constraining. I'm not a native speaker, so I
> > > > suppose you'd know what to use better.
> > > 
> > > Yeah I'm not sure, Yong might have a better idea.  But "constrain
> > > adjustment" doesn't sound right to my ears.
> > > 
> > > Googling, I see the phrasing "constraint adjustment" and "constrained
> > > adjustment", but not "constrain adjustment".
> > > 
> > > Poking through the google results, "constraint adjustment" are
> > > adjustments that implement different types of constraints.  "Constrained
> > > adjustments" are types of adjustments which are constrained (as opposed
> > > to "free adjustments" that are not constrained).  So maybe "constraint
> > > adjustment" might be the right terminology here, but I'm not certain.
> > > 
> > > Also I think you can just say, "constraint adjustment" rather than
> > > "constraint adjustment value".
> > 
> > Maybe thats better than. Do you mean the request name or just the
> > documentation should be updated, if we decide something other than
> > 'constrain adjustment' should be used.
> 
> I'm only suggesting the documentation be corrected.  If the request name
> also can be updated to be consistent that would be ideal, if it doesn't
> break the API.
>  
> > CC:ing Yong for some grammar input.
> > 
> > > 
> > > > > > +   What a constrained surface means is compositor specific, but it 
> > > > > > could
> > > > > > +   for example be partly outside of the work area of a monitor.
> > > > > 
> > > > > I'm not sure what this sentence means.
> > > > 
> > > > What I try to communicate is that what a 'constrained' surface is an
> > > > implementation detail.  Commonly 'constrained' means to be partly
> > > > outside of the work area (monitor region excluding panel etc), while
> > > > unconstrained completely within that work area. Do you have a better
> > > > suggestion?
> > > 
> > > Ah, I think I get it now.
> > > 
> > > Whether a surface is considered 'constrained' is left to the compositor
> > > to determine.  For example, the surface may be partly outside the
> > > compositor's defined 'work area', thus necessitating the child surface's
> > > position be adjusted until it is entirely inside the work area.
> > 
> > Right. Its meant to be a compositor implementation detail so that we can
> > do crazy things like 3D compositors where 'unconstrained' might mean its
> > "inside a wall in the 3D space", or "infinite work areas" where nothing is 
> > ever
> > unconstrained.
> 
> Ok, sounds good.  So I'd suggest using the text I wrote there, I think
> that might be a bit clearer.

Landed this one with the adjustment you suggested. Thanks.


Jonas

> 
> Bryce
> 
> > 

Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Bryce Harrington]

On Fri, Aug 12, 2016 at 12:44:49PM +0800, Jonas Ådahl wrote:
> On Thu, Aug 11, 2016 at 09:35:57PM -0700, Bryce Harrington wrote:
> > On Fri, Aug 12, 2016 at 11:56:13AM +0800, Jonas Ådahl wrote:
> > > On Thu, Aug 11, 2016 at 08:49:01PM -0700, Bryce Harrington wrote:
> > > > On Fri, Jul 29, 2016 at 12:04:55PM +0800, Jonas Ådahl wrote:
> > > > > In order to get feedback of available space where a client can create
> > > > > its popup, let it create requset that its popup rectangle being 
> > > > > resized
> > > > > would it not fit the within the work area. This adds two new constrain
> > > > > adjustment values to the adjustment enum, and dimension parameters to
> > > > > the xdg_popup.configure event.
> > > > > 
> > > > > The existing constrain adjustment actions take precedence, and 
> > > > > resizing
> > > > > will only be triggered if all other adjustments requested didn't 
> > > > > manage
> > > > > to make the popup rectangle fully visible.
> > > > > 
> > > > > Signed-off-by: Jonas Ådahl 
> > > > > Acked-by: Quentin Glidic 
> > > > > ---
> > > > > 
> > > > > Chances since v1: none
> > > > > 
> > > > > 
> > > > > 
> > > > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> > > > > +---
> > > > >  1 file changed, 30 insertions(+), 10 deletions(-)
> > > > > 
> > > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > index 2c8f636..ef45ff4 100644
> > > > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > @@ -249,6 +249,19 @@
> > > > >  
> > > > >  
> > > > >  
> > > > > +  
> > > > > + The constrain adjustment value define ways the compositor will 
> > > > > adjust
> > > > > + the position of the surface, if the unadjusted position would 
> > > > > result
> > > > > + in the surface being partly constrained.
> > > > 
> > > > "constraint adjustment" maybe?
> > > 
> > > Isn't 'constraint' the noun, and 'constrain' the verb? What I mean is
> > > the adjustment done while constraining. I'm not a native speaker, so I
> > > suppose you'd know what to use better.
> > 
> > Yeah I'm not sure, Yong might have a better idea.  But "constrain
> > adjustment" doesn't sound right to my ears.
> > 
> > Googling, I see the phrasing "constraint adjustment" and "constrained
> > adjustment", but not "constrain adjustment".
> > 
> > Poking through the google results, "constraint adjustment" are
> > adjustments that implement different types of constraints.  "Constrained
> > adjustments" are types of adjustments which are constrained (as opposed
> > to "free adjustments" that are not constrained).  So maybe "constraint
> > adjustment" might be the right terminology here, but I'm not certain.
> > 
> > Also I think you can just say, "constraint adjustment" rather than
> > "constraint adjustment value".
> 
> Maybe thats better than. Do you mean the request name or just the
> documentation should be updated, if we decide something other than
> 'constrain adjustment' should be used.

I'm only suggesting the documentation be corrected.  If the request name
also can be updated to be consistent that would be ideal, if it doesn't
break the API.
 
> CC:ing Yong for some grammar input.
> 
> > 
> > > > > + What a constrained surface means is compositor specific, but it 
> > > > > could
> > > > > + for example be partly outside of the work area of a monitor.
> > > > 
> > > > I'm not sure what this sentence means.
> > > 
> > > What I try to communicate is that what a 'constrained' surface is an
> > > implementation detail.  Commonly 'constrained' means to be partly
> > > outside of the work area (monitor region excluding panel etc), while
> > > unconstrained completely within that work area. Do you have a better
> > > suggestion?
> > 
> > Ah, I think I get it now.
> > 
> > Whether a surface is considered 'constrained' is left to the compositor
> > to determine.  For example, the surface may be partly outside the
> > compositor's defined 'work area', thus necessitating the child surface's
> > position be adjusted until it is entirely inside the work area.
> 
> Right. Its meant to be a compositor implementation detail so that we can
> do crazy things like 3D compositors where 'unconstrained' might mean its
> "inside a wall in the 3D space", or "infinite work areas" where nothing is 
> ever
> unconstrained.

Ok, sounds good.  So I'd suggest using the text I wrote there, I think
that might be a bit clearer.

Bryce

> Jonas
> 
> > 
> > > > > + Multiple constrain adjustment values can be combined, in which 
> > > > > case
> > > > > + they have a defined precedence. The order of adjustments is: 
> > > > > flip,
> > > > > + slide then resize.
> > > > 
> > > > The adjustments can be combined, according to a defined
> > > > precedence: 1) Flip, 2) Slide, 3) Resize.
> > > 

Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Yong Bakos]

Hi Jonas & Bryce,

> On Aug 11, 2016, at 9:44 PM, Jonas Ådahl  wrote:
> 
> On Thu, Aug 11, 2016 at 09:35:57PM -0700, Bryce Harrington wrote:
>> On Fri, Aug 12, 2016 at 11:56:13AM +0800, Jonas Ådahl wrote:
>>> On Thu, Aug 11, 2016 at 08:49:01PM -0700, Bryce Harrington wrote:
 On Fri, Jul 29, 2016 at 12:04:55PM +0800, Jonas Ådahl wrote:
> In order to get feedback of available space where a client can create
> its popup, let it create requset that its popup rectangle being resized
> would it not fit the within the work area. This adds two new constrain
> adjustment values to the adjustment enum, and dimension parameters to
> the xdg_popup.configure event.
> 
> The existing constrain adjustment actions take precedence, and resizing
> will only be triggered if all other adjustments requested didn't manage
> to make the popup rectangle fully visible.
> 
> Signed-off-by: Jonas Ådahl 
> Acked-by: Quentin Glidic 
> ---
> 
> Chances since v1: none
> 
> 
> 
> unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> +---
> 1 file changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 2c8f636..ef45ff4 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -249,6 +249,19 @@
> 
> 
> 
> +  
> + The constrain adjustment value define ways the compositor will adjust
> + the position of the surface, if the unadjusted position would result
> + in the surface being partly constrained.
 
 "constraint adjustment" maybe?
>>> 
>>> Isn't 'constraint' the noun, and 'constrain' the verb? What I mean is
>>> the adjustment done while constraining. I'm not a native speaker, so I
>>> suppose you'd know what to use better.
>> 
>> Yeah I'm not sure, Yong might have a better idea.  But "constrain
>> adjustment" doesn't sound right to my ears.
>> 

I thought of this a while back as well, and the 'right' solution, in my
opinion, would be to rename the enum to constraint_adjustment but also
to go with "The constraint adjustment value" - matching the description
summary. For some reason I resisted suggesting renaming the enum, but I
guess I'm doing that now, FWIW.

yong



>> Googling, I see the phrasing "constraint adjustment" and "constrained
>> adjustment", but not "constrain adjustment".
>> 
>> Poking through the google results, "constraint adjustment" are
>> adjustments that implement different types of constraints.  "Constrained
>> adjustments" are types of adjustments which are constrained (as opposed
>> to "free adjustments" that are not constrained).  So maybe "constraint
>> adjustment" might be the right terminology here, but I'm not certain.
>> 
>> Also I think you can just say, "constraint adjustment" rather than
>> "constraint adjustment value".
> 
> Maybe thats better than. Do you mean the request name or just the
> documentation should be updated, if we decide something other than
> 'constrain adjustment' should be used.
> 
> CC:ing Yong for some grammar input.
> 
>> 
> + What a constrained surface means is compositor specific, but it could
> + for example be partly outside of the work area of a monitor.
 
 I'm not sure what this sentence means.
>>> 
>>> What I try to communicate is that what a 'constrained' surface is an
>>> implementation detail.  Commonly 'constrained' means to be partly
>>> outside of the work area (monitor region excluding panel etc), while
>>> unconstrained completely within that work area. Do you have a better
>>> suggestion?
>> 
>> Ah, I think I get it now.
>> 
>> Whether a surface is considered 'constrained' is left to the compositor
>> to determine.  For example, the surface may be partly outside the
>> compositor's defined 'work area', thus necessitating the child surface's
>> position be adjusted until it is entirely inside the work area.
> 
> Right. Its meant to be a compositor implementation detail so that we can
> do crazy things like 3D compositors where 'unconstrained' might mean its
> "inside a wall in the 3D space", or "infinite work areas" where nothing is 
> ever
> unconstrained.
> 
> 
> Jonas
> 
>> 
> + Multiple constrain adjustment values can be combined, in which case
> + they have a defined precedence. The order of adjustments is: flip,
> + slide then resize.
 
The adjustments can be combined, according to a defined
precedence: 1) Flip, 2) Slide, 3) Resize.
>>> 
>>> Thanks, thats better.
>>> 
>>> 
>>> Jonas
>> 
>> Bryce
>> 
 
> +  
> +
>   
>   
> Don't alter the surface position even if it is constrained on some
> @@ -268,8 +281,6 @@
> x axis until either the edge in the direction 

Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Jonas Ådahl]

On Thu, Aug 11, 2016 at 09:35:57PM -0700, Bryce Harrington wrote:
> On Fri, Aug 12, 2016 at 11:56:13AM +0800, Jonas Ådahl wrote:
> > On Thu, Aug 11, 2016 at 08:49:01PM -0700, Bryce Harrington wrote:
> > > On Fri, Jul 29, 2016 at 12:04:55PM +0800, Jonas Ådahl wrote:
> > > > In order to get feedback of available space where a client can create
> > > > its popup, let it create requset that its popup rectangle being resized
> > > > would it not fit the within the work area. This adds two new constrain
> > > > adjustment values to the adjustment enum, and dimension parameters to
> > > > the xdg_popup.configure event.
> > > > 
> > > > The existing constrain adjustment actions take precedence, and resizing
> > > > will only be triggered if all other adjustments requested didn't manage
> > > > to make the popup rectangle fully visible.
> > > > 
> > > > Signed-off-by: Jonas Ådahl 
> > > > Acked-by: Quentin Glidic 
> > > > ---
> > > > 
> > > > Chances since v1: none
> > > > 
> > > > 
> > > > 
> > > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> > > > +---
> > > >  1 file changed, 30 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > index 2c8f636..ef45ff4 100644
> > > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > @@ -249,6 +249,19 @@
> > > >  
> > > >  
> > > >  
> > > > +  
> > > > +   The constrain adjustment value define ways the compositor will 
> > > > adjust
> > > > +   the position of the surface, if the unadjusted position would 
> > > > result
> > > > +   in the surface being partly constrained.
> > > 
> > > "constraint adjustment" maybe?
> > 
> > Isn't 'constraint' the noun, and 'constrain' the verb? What I mean is
> > the adjustment done while constraining. I'm not a native speaker, so I
> > suppose you'd know what to use better.
> 
> Yeah I'm not sure, Yong might have a better idea.  But "constrain
> adjustment" doesn't sound right to my ears.
> 
> Googling, I see the phrasing "constraint adjustment" and "constrained
> adjustment", but not "constrain adjustment".
> 
> Poking through the google results, "constraint adjustment" are
> adjustments that implement different types of constraints.  "Constrained
> adjustments" are types of adjustments which are constrained (as opposed
> to "free adjustments" that are not constrained).  So maybe "constraint
> adjustment" might be the right terminology here, but I'm not certain.
> 
> Also I think you can just say, "constraint adjustment" rather than
> "constraint adjustment value".

Maybe thats better than. Do you mean the request name or just the
documentation should be updated, if we decide something other than
'constrain adjustment' should be used.

CC:ing Yong for some grammar input.

> 
> > > > +   What a constrained surface means is compositor specific, but it 
> > > > could
> > > > +   for example be partly outside of the work area of a monitor.
> > > 
> > > I'm not sure what this sentence means.
> > 
> > What I try to communicate is that what a 'constrained' surface is an
> > implementation detail.  Commonly 'constrained' means to be partly
> > outside of the work area (monitor region excluding panel etc), while
> > unconstrained completely within that work area. Do you have a better
> > suggestion?
> 
> Ah, I think I get it now.
> 
> Whether a surface is considered 'constrained' is left to the compositor
> to determine.  For example, the surface may be partly outside the
> compositor's defined 'work area', thus necessitating the child surface's
> position be adjusted until it is entirely inside the work area.

Right. Its meant to be a compositor implementation detail so that we can
do crazy things like 3D compositors where 'unconstrained' might mean its
"inside a wall in the 3D space", or "infinite work areas" where nothing is ever
unconstrained.


Jonas

> 
> > > > +   Multiple constrain adjustment values can be combined, in which 
> > > > case
> > > > +   they have a defined precedence. The order of adjustments is: 
> > > > flip,
> > > > +   slide then resize.
> > > 
> > >   The adjustments can be combined, according to a defined
> > >   precedence: 1) Flip, 2) Slide, 3) Resize.
> > 
> > Thanks, thats better.
> > 
> > 
> > Jonas
> 
> Bryce
> 
> > > 
> > > > +  
> > > > +
> > > >
> > > > 
> > > >   Don't alter the surface position even if it is constrained on 
> > > > some
> > > > @@ -268,8 +281,6 @@
> > > >   x axis until either the edge in the direction of the gravity 
> > > > is
> > > >   unconstrained or the edge in the opposite direction of the 
> > > > gravity is
> > > >   constrained.
> > > > -
> > > > - If 'slide_x' is combined with 'flip_x', 'flip_x' takes 
> > > > 

Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Bryce Harrington]

On Fri, Aug 12, 2016 at 11:56:13AM +0800, Jonas Ådahl wrote:
> On Thu, Aug 11, 2016 at 08:49:01PM -0700, Bryce Harrington wrote:
> > On Fri, Jul 29, 2016 at 12:04:55PM +0800, Jonas Ådahl wrote:
> > > In order to get feedback of available space where a client can create
> > > its popup, let it create requset that its popup rectangle being resized
> > > would it not fit the within the work area. This adds two new constrain
> > > adjustment values to the adjustment enum, and dimension parameters to
> > > the xdg_popup.configure event.
> > > 
> > > The existing constrain adjustment actions take precedence, and resizing
> > > will only be triggered if all other adjustments requested didn't manage
> > > to make the popup rectangle fully visible.
> > > 
> > > Signed-off-by: Jonas Ådahl 
> > > Acked-by: Quentin Glidic 
> > > ---
> > > 
> > > Chances since v1: none
> > > 
> > > 
> > > 
> > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> > > +---
> > >  1 file changed, 30 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > index 2c8f636..ef45ff4 100644
> > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > @@ -249,6 +249,19 @@
> > >  
> > >  
> > >  
> > > +  
> > > + The constrain adjustment value define ways the compositor will adjust
> > > + the position of the surface, if the unadjusted position would result
> > > + in the surface being partly constrained.
> > 
> > "constraint adjustment" maybe?
> 
> Isn't 'constraint' the noun, and 'constrain' the verb? What I mean is
> the adjustment done while constraining. I'm not a native speaker, so I
> suppose you'd know what to use better.

Yeah I'm not sure, Yong might have a better idea.  But "constrain
adjustment" doesn't sound right to my ears.

Googling, I see the phrasing "constraint adjustment" and "constrained
adjustment", but not "constrain adjustment".

Poking through the google results, "constraint adjustment" are
adjustments that implement different types of constraints.  "Constrained
adjustments" are types of adjustments which are constrained (as opposed
to "free adjustments" that are not constrained).  So maybe "constraint
adjustment" might be the right terminology here, but I'm not certain.

Also I think you can just say, "constraint adjustment" rather than
"constraint adjustment value".

> > > + What a constrained surface means is compositor specific, but it could
> > > + for example be partly outside of the work area of a monitor.
> > 
> > I'm not sure what this sentence means.
> 
> What I try to communicate is that what a 'constrained' surface is an
> implementation detail.  Commonly 'constrained' means to be partly
> outside of the work area (monitor region excluding panel etc), while
> unconstrained completely within that work area. Do you have a better
> suggestion?

Ah, I think I get it now.

Whether a surface is considered 'constrained' is left to the compositor
to determine.  For example, the surface may be partly outside the
compositor's defined 'work area', thus necessitating the child surface's
position be adjusted until it is entirely inside the work area.

> > > + Multiple constrain adjustment values can be combined, in which case
> > > + they have a defined precedence. The order of adjustments is: flip,
> > > + slide then resize.
> > 
> > The adjustments can be combined, according to a defined
> > precedence: 1) Flip, 2) Slide, 3) Resize.
> 
> Thanks, thats better.
> 
> 
> Jonas

Bryce

> > 
> > > +  
> > > +
> > >
> > >   
> > > Don't alter the surface position even if it is constrained on some
> > > @@ -268,8 +281,6 @@
> > > x axis until either the edge in the direction of the gravity is
> > > unconstrained or the edge in the opposite direction of the gravity is
> > > constrained.
> > > -
> > > -   If 'slide_x' is combined with 'flip_x', 'flip_x' takes precedence.
> > >   
> > >
> > >
> > > @@ -285,8 +296,6 @@
> > > y axis until either the edge in the direction of the gravity is
> > > unconstrained or the edge in the opposite direction of the gravity is
> > > constrained.
> > > -
> > > -   If 'slide_y' is combined with 'flip_y', 'flip_y' takes precedence.
> > >   
> > >
> > >
> > > @@ -297,9 +306,8 @@
> > > 'left', change the gravity to 'right' and the anchor to 'right'.
> > >  
> > > If the adjusted position also ends up being constrained, the resulting
> > > -   position will be the one before the adjustment. If the resulting
> > > -   position is still constrained, and 'flip_x' is combined with
> > > -   'slide_x', the position is adjusted according to 'slide_x'.
> > > +   position of the flip_x adjustment will be the one before the
> > > +   adjustment.
> > >   
> > >
> > >   

Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Jonas Ådahl]

On Thu, Aug 11, 2016 at 08:49:01PM -0700, Bryce Harrington wrote:
> On Fri, Jul 29, 2016 at 12:04:55PM +0800, Jonas Ådahl wrote:
> > In order to get feedback of available space where a client can create
> > its popup, let it create requset that its popup rectangle being resized
> > would it not fit the within the work area. This adds two new constrain
> > adjustment values to the adjustment enum, and dimension parameters to
> > the xdg_popup.configure event.
> > 
> > The existing constrain adjustment actions take precedence, and resizing
> > will only be triggered if all other adjustments requested didn't manage
> > to make the popup rectangle fully visible.
> > 
> > Signed-off-by: Jonas Ådahl 
> > Acked-by: Quentin Glidic 
> > ---
> > 
> > Chances since v1: none
> > 
> > 
> > 
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> > +---
> >  1 file changed, 30 insertions(+), 10 deletions(-)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 2c8f636..ef45ff4 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -249,6 +249,19 @@
> >  
> >  
> >  
> > +  
> > +   The constrain adjustment value define ways the compositor will adjust
> > +   the position of the surface, if the unadjusted position would result
> > +   in the surface being partly constrained.
> 
> "constraint adjustment" maybe?

Isn't 'constraint' the noun, and 'constrain' the verb? What I mean is
the adjustment done while constraining. I'm not a native speaker, so I
suppose you'd know what to use better.

> 
> > +   What a constrained surface means is compositor specific, but it could
> > +   for example be partly outside of the work area of a monitor.
> 
> I'm not sure what this sentence means.

What I try to communicate is that what a 'constrained' surface is an
implementation detail. Commonly 'constrained' means to be partly outside
of the work area (monitor region excluding panel etc), while
unconstrained completely within that work area. Do you have a better
suggestion?

> 
> > +   Multiple constrain adjustment values can be combined, in which case
> > +   they have a defined precedence. The order of adjustments is: flip,
> > +   slide then resize.
> 
>   The adjustments can be combined, according to a defined
>   precedence: 1) Flip, 2) Slide, 3) Resize.

Thanks, thats better.


Jonas

> 
> > +  
> > +
> >
> > 
> >   Don't alter the surface position even if it is constrained on some
> > @@ -268,8 +281,6 @@
> >   x axis until either the edge in the direction of the gravity is
> >   unconstrained or the edge in the opposite direction of the gravity is
> >   constrained.
> > -
> > - If 'slide_x' is combined with 'flip_x', 'flip_x' takes precedence.
> > 
> >
> >
> > @@ -285,8 +296,6 @@
> >   y axis until either the edge in the direction of the gravity is
> >   unconstrained or the edge in the opposite direction of the gravity is
> >   constrained.
> > -
> > - If 'slide_y' is combined with 'flip_y', 'flip_y' takes precedence.
> > 
> >
> >
> > @@ -297,9 +306,8 @@
> >   'left', change the gravity to 'right' and the anchor to 'right'.
> >  
> >   If the adjusted position also ends up being constrained, the resulting
> > - position will be the one before the adjustment. If the resulting
> > - position is still constrained, and 'flip_x' is combined with
> > - 'slide_x', the position is adjusted according to 'slide_x'.
> > + position of the flip_x adjustment will be the one before the
> > + adjustment.
> > 
> >
> >
> > @@ -310,9 +318,19 @@
> >   'bottom', change the gravity to 'top' and the anchor to 'top'.
> >  
> >   If the adjusted position also ends up being constrained, the resulting
> > - position will be the one before the adjustment. If the resulting
> > - position is still constrained, and 'flip_y' is combined with
> > - 'slide_y', the position is adjusted according to 'slide_y'.
> > + position of the flip_y adjustment will be the one before the
> > + adjustment.
> > +   
> > +  
> > +  
> > +   
> > + Resize the surface horizontally so that it is completely
> > + unconstrained.
> > +   
> > +  
> > +  
> > +   
> > + Resize the surface vertically so that it is completely unconstrained.
> > 
> >
> >  
> > @@ -1039,6 +1057,8 @@
> >summary="x position relative to parent surface window geometry"/>
> > >summary="y position relative to parent surface window geometry"/>
> > +  
> > +  
> >  
> >  
> >  
> > -- 
> > 2.7.4
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > 

Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Bryce Harrington]

On Fri, Jul 29, 2016 at 12:04:55PM +0800, Jonas Ådahl wrote:
> In order to get feedback of available space where a client can create
> its popup, let it create requset that its popup rectangle being resized
> would it not fit the within the work area. This adds two new constrain
> adjustment values to the adjustment enum, and dimension parameters to
> the xdg_popup.configure event.
> 
> The existing constrain adjustment actions take precedence, and resizing
> will only be triggered if all other adjustments requested didn't manage
> to make the popup rectangle fully visible.
> 
> Signed-off-by: Jonas Ådahl 
> Acked-by: Quentin Glidic 
> ---
> 
> Chances since v1: none
> 
> 
> 
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> +---
>  1 file changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 2c8f636..ef45ff4 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -249,6 +249,19 @@
>  
>  
>  
> +  
> + The constrain adjustment value define ways the compositor will adjust
> + the position of the surface, if the unadjusted position would result
> + in the surface being partly constrained.

"constraint adjustment" maybe?

> + What a constrained surface means is compositor specific, but it could
> + for example be partly outside of the work area of a monitor.

I'm not sure what this sentence means.

> + Multiple constrain adjustment values can be combined, in which case
> + they have a defined precedence. The order of adjustments is: flip,
> + slide then resize.

The adjustments can be combined, according to a defined
precedence: 1) Flip, 2) Slide, 3) Resize.

> +  
> +
>
>   
> Don't alter the surface position even if it is constrained on some
> @@ -268,8 +281,6 @@
> x axis until either the edge in the direction of the gravity is
> unconstrained or the edge in the opposite direction of the gravity is
> constrained.
> -
> -   If 'slide_x' is combined with 'flip_x', 'flip_x' takes precedence.
>   
>
>
> @@ -285,8 +296,6 @@
> y axis until either the edge in the direction of the gravity is
> unconstrained or the edge in the opposite direction of the gravity is
> constrained.
> -
> -   If 'slide_y' is combined with 'flip_y', 'flip_y' takes precedence.
>   
>
>
> @@ -297,9 +306,8 @@
> 'left', change the gravity to 'right' and the anchor to 'right'.
>  
> If the adjusted position also ends up being constrained, the resulting
> -   position will be the one before the adjustment. If the resulting
> -   position is still constrained, and 'flip_x' is combined with
> -   'slide_x', the position is adjusted according to 'slide_x'.
> +   position of the flip_x adjustment will be the one before the
> +   adjustment.
>   
>
>
> @@ -310,9 +318,19 @@
> 'bottom', change the gravity to 'top' and the anchor to 'top'.
>  
> If the adjusted position also ends up being constrained, the resulting
> -   position will be the one before the adjustment. If the resulting
> -   position is still constrained, and 'flip_y' is combined with
> -   'slide_y', the position is adjusted according to 'slide_y'.
> +   position of the flip_y adjustment will be the one before the
> +   adjustment.
> + 
> +  
> +  
> + 
> +   Resize the surface horizontally so that it is completely
> +   unconstrained.
> + 
> +  
> +  
> + 
> +   Resize the surface vertically so that it is completely unconstrained.
>   
>
>  
> @@ -1039,6 +1057,8 @@
>  summary="x position relative to parent surface window geometry"/>
>  summary="y position relative to parent surface window geometry"/>
> +  
> +  
>  
>  
>  
> -- 
> 2.7.4
> 
> ___
> 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 wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Jonas Ådahl]

On Fri, Jul 29, 2016 at 10:58:47AM +0200, Quentin Glidic wrote:
> On 29/07/2016 06:04, Jonas Ådahl wrote:
> > In order to get feedback of available space where a client can create
> > its popup, let it create requset that its popup rectangle being resized
> > would it not fit the within the work area. This adds two new constrain
> > adjustment values to the adjustment enum, and dimension parameters to
> > the xdg_popup.configure event.
> > 
> > The existing constrain adjustment actions take precedence, and resizing
> > will only be triggered if all other adjustments requested didn't manage
> > to make the popup rectangle fully visible.
> > 
> > Signed-off-by: Jonas Ådahl 
> > Acked-by: Quentin Glidic 
> > ---
> >
> > Chances since v1: none
> 
> Shouldn’t you have squashed with the positioner patch directly?

Could have, but the positioner patch is closer to being landable, so I
let it have only minor changes in this iteration, and continued to have
this as a separate patch.


Jonas

> 
> Cheers,
> 
> 
> > 
> > 
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 
> > +---
> >  1 file changed, 30 insertions(+), 10 deletions(-)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 2c8f636..ef45ff4 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -249,6 +249,19 @@
> >  
> > 
> >  
> > +  
> > +   The constrain adjustment value define ways the compositor will adjust
> > +   the position of the surface, if the unadjusted position would result
> > +   in the surface being partly constrained.
> > +
> > +   What a constrained surface means is compositor specific, but it could
> > +   for example be partly outside of the work area of a monitor.
> > +
> > +   Multiple constrain adjustment values can be combined, in which case
> > +   they have a defined precedence. The order of adjustments is: flip,
> > +   slide then resize.
> > +  
> > +
> >
> > 
> >   Don't alter the surface position even if it is constrained on some
> > @@ -268,8 +281,6 @@
> >   x axis until either the edge in the direction of the gravity is
> >   unconstrained or the edge in the opposite direction of the gravity is
> >   constrained.
> > -
> > - If 'slide_x' is combined with 'flip_x', 'flip_x' takes precedence.
> > 
> >
> >
> > @@ -285,8 +296,6 @@
> >   y axis until either the edge in the direction of the gravity is
> >   unconstrained or the edge in the opposite direction of the gravity is
> >   constrained.
> > -
> > - If 'slide_y' is combined with 'flip_y', 'flip_y' takes precedence.
> > 
> >
> >
> > @@ -297,9 +306,8 @@
> >   'left', change the gravity to 'right' and the anchor to 'right'.
> > 
> >   If the adjusted position also ends up being constrained, the resulting
> > - position will be the one before the adjustment. If the resulting
> > - position is still constrained, and 'flip_x' is combined with
> > - 'slide_x', the position is adjusted according to 'slide_x'.
> > + position of the flip_x adjustment will be the one before the
> > + adjustment.
> > 
> >
> >
> > @@ -310,9 +318,19 @@
> >   'bottom', change the gravity to 'top' and the anchor to 'top'.
> > 
> >   If the adjusted position also ends up being constrained, the resulting
> > - position will be the one before the adjustment. If the resulting
> > - position is still constrained, and 'flip_y' is combined with
> > - 'slide_y', the position is adjusted according to 'slide_y'.
> > + position of the flip_y adjustment will be the one before the
> > + adjustment.
> > +   
> > +  
> > +  
> > +   
> > + Resize the surface horizontally so that it is completely
> > + unconstrained.
> > +   
> > +  
> > +  
> > +   
> > + Resize the surface vertically so that it is completely unconstrained.
> > 
> >
> >  
> > @@ -1039,6 +1057,8 @@
> >summary="x position relative to parent surface window geometry"/>
> > >summary="y position relative to parent surface window geometry"/>
> > +  
> > +  
> >  
> > 
> >  
> > 
> 
> 
> -- 
> 
> Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Quentin Glidic]

On 29/07/2016 06:04, Jonas Ådahl wrote:

In order to get feedback of available space where a client can create
its popup, let it create requset that its popup rectangle being resized
would it not fit the within the work area. This adds two new constrain
adjustment values to the adjustment enum, and dimension parameters to
the xdg_popup.configure event.

The existing constrain adjustment actions take precedence, and resizing
will only be triggered if all other adjustments requested didn't manage
to make the popup rectangle fully visible.

Signed-off-by: Jonas Ådahl 
Acked-by: Quentin Glidic 
---

>

Chances since v1: none


Shouldn’t you have squashed with the positioner patch directly?

Cheers,





 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 +---
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 2c8f636..ef45ff4 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -249,6 +249,19 @@
 

 
+  
+   The constrain adjustment value define ways the compositor will adjust
+   the position of the surface, if the unadjusted position would result
+   in the surface being partly constrained.
+
+   What a constrained surface means is compositor specific, but it could
+   for example be partly outside of the work area of a monitor.
+
+   Multiple constrain adjustment values can be combined, in which case
+   they have a defined precedence. The order of adjustments is: flip,
+   slide then resize.
+  
+
   

  Don't alter the surface position even if it is constrained on some
@@ -268,8 +281,6 @@
  x axis until either the edge in the direction of the gravity is
  unconstrained or the edge in the opposite direction of the gravity is
  constrained.
-
- If 'slide_x' is combined with 'flip_x', 'flip_x' takes precedence.

   
   
@@ -285,8 +296,6 @@
  y axis until either the edge in the direction of the gravity is
  unconstrained or the edge in the opposite direction of the gravity is
  constrained.
-
- If 'slide_y' is combined with 'flip_y', 'flip_y' takes precedence.

   
   
@@ -297,9 +306,8 @@
  'left', change the gravity to 'right' and the anchor to 'right'.

  If the adjusted position also ends up being constrained, the resulting
- position will be the one before the adjustment. If the resulting
- position is still constrained, and 'flip_x' is combined with
- 'slide_x', the position is adjusted according to 'slide_x'.
+ position of the flip_x adjustment will be the one before the
+ adjustment.

   
   
@@ -310,9 +318,19 @@
  'bottom', change the gravity to 'top' and the anchor to 'top'.

  If the adjusted position also ends up being constrained, the resulting
- position will be the one before the adjustment. If the resulting
- position is still constrained, and 'flip_y' is combined with
- 'slide_y', the position is adjusted according to 'slide_y'.
+ position of the flip_y adjustment will be the one before the
+ adjustment.
+   
+  
+  
+   
+ Resize the surface horizontally so that it is completely
+ unconstrained.
+   
+  
+  
+   
+ Resize the surface vertically so that it is completely unconstrained.

   
 
@@ -1039,6 +1057,8 @@
   summary="x position relative to parent surface window geometry"/>
   
+  
+  
 

 




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-protocols 3/4 v2] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Jonas Ådahl]

In order to get feedback of available space where a client can create
its popup, let it create requset that its popup rectangle being resized
would it not fit the within the work area. This adds two new constrain
adjustment values to the adjustment enum, and dimension parameters to
the xdg_popup.configure event.

The existing constrain adjustment actions take precedence, and resizing
will only be triggered if all other adjustments requested didn't manage
to make the popup rectangle fully visible.

Signed-off-by: Jonas Ådahl 
Acked-by: Quentin Glidic 
---

Chances since v1: none



 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 +---
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 2c8f636..ef45ff4 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -249,6 +249,19 @@
 
 
 
+  
+   The constrain adjustment value define ways the compositor will adjust
+   the position of the surface, if the unadjusted position would result
+   in the surface being partly constrained.
+
+   What a constrained surface means is compositor specific, but it could
+   for example be partly outside of the work area of a monitor.
+
+   Multiple constrain adjustment values can be combined, in which case
+   they have a defined precedence. The order of adjustments is: flip,
+   slide then resize.
+  
+
   

  Don't alter the surface position even if it is constrained on some
@@ -268,8 +281,6 @@
  x axis until either the edge in the direction of the gravity is
  unconstrained or the edge in the opposite direction of the gravity is
  constrained.
-
- If 'slide_x' is combined with 'flip_x', 'flip_x' takes precedence.

   
   
@@ -285,8 +296,6 @@
  y axis until either the edge in the direction of the gravity is
  unconstrained or the edge in the opposite direction of the gravity is
  constrained.
-
- If 'slide_y' is combined with 'flip_y', 'flip_y' takes precedence.

   
   
@@ -297,9 +306,8 @@
  'left', change the gravity to 'right' and the anchor to 'right'.
 
  If the adjusted position also ends up being constrained, the resulting
- position will be the one before the adjustment. If the resulting
- position is still constrained, and 'flip_x' is combined with
- 'slide_x', the position is adjusted according to 'slide_x'.
+ position of the flip_x adjustment will be the one before the
+ adjustment.

   
   
@@ -310,9 +318,19 @@
  'bottom', change the gravity to 'top' and the anchor to 'top'.
 
  If the adjusted position also ends up being constrained, the resulting
- position will be the one before the adjustment. If the resulting
- position is still constrained, and 'flip_y' is combined with
- 'slide_y', the position is adjusted according to 'slide_y'.
+ position of the flip_y adjustment will be the one before the
+ adjustment.
+   
+  
+  
+   
+ Resize the surface horizontally so that it is completely
+ unconstrained.
+   
+  
+  
+   
+ Resize the surface vertically so that it is completely unconstrained.

   
 
@@ -1039,6 +1057,8 @@
   summary="x position relative to parent surface window geometry"/>
   
+  
+  
 
 
 
-- 
2.7.4

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