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

Yong Bakos junk at humanoriented.com
Fri Aug 12 17:14:06 UTC 2016


Hi Jonas & Bryce,

> On Aug 11, 2016, at 9:44 PM, Jonas Ådahl <jadahl at gmail.com> 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 <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.
>> 

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
>> 
>>>> 
>>>>> +      </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



More information about the wayland-devel mailing list