[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