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

Fri Aug 12 04:44:49 UTC 2016

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 <jadahl at gmail.com>
> > > > Acked-by: Quentin Glidic <sardemff7+git at sardemff7.net>
> > > > ---
> > > > 
> > > > 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 @@
> > > >      </request>
> > > >  
> > > >      <enum name="constrain_adjustment" bitfield="true">
> > > > +      <description summary="constraint adjustments">
> > > > +	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
> 
> > > 
> > > > +      </description>
> > > > +
> > > >        <entry name="none" value="0">
> > > >  	<description summary="don't move the child surface when constrained">
> > > >  	  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.
> > > >  	</description>
> > > >        </entry>
> > > >        <entry name="slide_y" value="2">
> > > > @@ -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.
> > > >  	</description>
> > > >        </entry>
> > > >        <entry name="flip_x" value="4">
> > > > @@ -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.
> > > >  	</description>
> > > >        </entry>
> > > >        <entry name="flip_y" value="8">
> > > > @@ -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.
> > > > +	</description>
> > > > +      </entry>
> > > > +      <entry name="resize_x" value="16">
> > > > +	<description summary="horizontally resize the surface">
> > > > +	  Resize the surface horizontally so that it is completely
> > > > +	  unconstrained.
> > > > +	</description>
> > > > +      </entry>
> > > > +      <entry name="resize_y" value="32">
> > > > +	<description summary="vertically resize the surface">
> > > > +	  Resize the surface vertically so that it is completely unconstrained.
> > > >  	</description>
> > > >        </entry>
> > > >      </enum>
> > > > @@ -1039,6 +1057,8 @@
> > > >  	   summary="x position relative to parent surface window geometry"/>
> > > >        <arg name="y" type="int"
> > > >  	   summary="y position relative to parent surface window geometry"/>
> > > > +      <arg name="width" type="int" summary="window geometry width"/>
> > > > +      <arg name="height" type="int" summary="window geometry height"/>
> > > >      </event>
> > > >  
> > > >      <event name="popup_done">
> > > > -- 
> > > > 2.7.4
> > > > 
> > > > _______________________________________________
> > > > wayland-devel mailing list
> > > > wayland-devel at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel