[PATCH wayland-protocols v3 6/7] xdg-shell: Make xdg_popup non-grabbing by default
Giulio Camuffo
giuliocamuffo at gmail.com
Wed Jun 8 08:07:46 UTC 2016
2016-06-08 3:08 GMT+02:00 Jonas Ådahl <jadahl at gmail.com>:
> On Tue, Jun 07, 2016 at 05:39:09PM +0300, Giulio Camuffo wrote:
>> Hi, a couple of comments below:
>>
>> 2016-05-26 7:32 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
>> > Turn xdg_popup into plain temporary child surfaces without any grabbing
>> > or mapping order requirements by default.
>> >
>> > In order to create grabbing popup chains, a new request 'grab' is
>> > introduced which enables more or less the same semantics and
>> > requirements as xdg_popup previously had related to grabbing, stacking
>> > and mapping order.
>> >
>> > This enables using xdg_popup for creating tooltips and other user
>> > interface elements that does not want to take an explicit grab.
>> >
>> > Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
>> > Signed-off-by: Mike Blumenkrantz <zmike at samsung.com>
>> > Reviewed-by: Yong Bakos <ybakos at humanoriented.com>
>> > ---
>> > unstable/xdg-shell/xdg-shell-unstable-v6.xml | 110 +++++++++++++++++----------
>> > 1 file changed, 68 insertions(+), 42 deletions(-)
>> >
>> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > index 2fdcf9b..07cbbc9 100644
>> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > @@ -158,16 +158,11 @@
>> > This creates an xdg_popup object for the given xdg_surface and gives the
>> > associated wl_surface the xdg_popup role.
>> >
>> > - This request must be used in response to some sort of user action like a
>> > - button press, key press, or touch down event.
>> > -
>> > See the documentation of xdg_popup for more details about what an
>> > xdg_popup is and how it is used.
>> > </description>
>> > <arg name="id" type="new_id" interface="zxdg_popup_v6"/>
>> > <arg name="parent" type="object" interface="zxdg_surface_v6"/>
>> > - <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
>> > - <arg name="serial" type="uint" summary="the serial of the user event"/>
>> > <arg name="x" type="int"/>
>> > <arg name="y" type="int"/>
>> > </request>
>> > @@ -670,46 +665,30 @@
>> >
>> > <interface name="zxdg_popup_v6" version="1">
>> > <description summary="short-lived, popup surfaces for menus">
>> > - A popup surface is a short-lived, temporary surface that can be
>> > - used to implement menus. It takes an explicit grab on the surface
>> > - that will be dismissed when the user dismisses the popup. This can
>> > - be done by the user clicking outside the surface, using the keyboard,
>> > - or even locking the screen through closing the lid or a timeout.
>> > -
>> > - When the popup is dismissed, a popup_done event will be sent out,
>> > - and at the same time the surface will be unmapped. The xdg_popup
>> > - object is now inert and cannot be reactivated, so clients should
>> > - destroy it. Explicitly destroying the xdg_popup object will also
>> > - dismiss the popup and unmap the surface.
>> > -
>> > - Clients will receive events for all their surfaces during this
>> > - grab (which is an "owner-events" grab in X11 parlance). This is
>> > - done so that users can navigate through submenus and other
>> > - "nested" popup windows without having to dismiss the topmost
>> > - popup.
>> > -
>> > - Clients that want to dismiss the popup when another surface of
>> > - their own is clicked should dismiss the popup using the destroy
>> > + A popup surface is a short-lived, temporary surface. It can be used to
>> > + implement for example menus, popovers, tooltips and other similar user
>> > + interface concepts.
>> > +
>> > + A popup can be made to take an explicit grab. See xdg_popup.grab for
>> > + details.
>> > +
>> > + When the popup is dismissed, a popup_done event will be sent out, and at
>> > + the same time the surface will be unmapped. See the xdg_popup.popup_done
>> > + event for details.
>> > +
>> > + Explicitly destroying the xdg_popup object will also dismiss the popup and
>> > + unmap the surface. Clients that want to dismiss the popup when another
>> > + surface of their own is clicked should dismiss the popup using the destroy
>> > request.
>> >
>> > The parent surface must have either the xdg_toplevel or xdg_popup surface
>> > role.
>> >
>> > - Specifying an xdg_popup for the parent means that the popups are
>> > - nested, with this popup now being the topmost popup. Nested
>> > - popups must be destroyed in the reverse order they were created
>> > - in, e.g. the only popup you are allowed to destroy at all times
>> > - is the topmost one.
>> > -
>> > - If there is an existing popup when creating a new popup, the
>> > - parent must be the current topmost popup.
>> > -
>> > - A parent surface must be mapped before the new popup is mapped.
>> > + A newly created xdg_popup will be stacked on top of all previously created
>> > + xdg_popup surfaces associated with the same xdg_toplevel.
>> >
>> > - When compositors choose to dismiss a popup, they will likely
>> > - dismiss every nested popup as well. When a compositor dismisses
>> > - popups, it will follow the same dismissing order as required
>> > - from the client.
>> > + The parent of an xdg_popup must be mapped (see the xdg_surface
>> > + description) before the xdg_popup itself.
>> >
>> > The x and y arguments passed when creating the popup object specify
>> > where the top left of the popup should be placed, relative to the
>> > @@ -718,9 +697,6 @@
>> >
>> > The client must call wl_surface.commit on the corresponding wl_surface
>> > for the xdg_popup state to take effect.
>> > -
>> > - For a surface to be mapped by the compositor the client must have
>> > - committed both the xdg_popup state and a buffer.
>> > </description>
>> >
>> > <request name="destroy" type="destructor">
>> > @@ -733,6 +709,56 @@
>> > </description>
>> > </request>
>> >
>> > + <request name="grab">
>> > + <description summary="make the popup take an explicit grab">
>> > + This request makes the created popup take an explicit grab. An explicit
>> > + grab will be dismissed when the user dismisses the popup, or when the
>> > + client destroys the xdg_popup. This can be done by the user clicking
>> > + outside the surface, using the keyboard, or even locking the screen
>> > + through closing the lid or a timeout.
>> > +
>> > + If the compositor denies the grab, the popup will be immediately
>> > + dismissed.
>> > +
>> > + This request must be used in response to some sort of user action like a
>> > + button press, key press, or touch down event. The serial number of the
>> > + event should be passed as 'serial'.
>> > +
>> > + The parent of a grabbing popup must either be a xdg_toplevel surface or
>> > + another xdg_popup with an explicit grab. If the parent is another
>> > + xdg_popup it means that the popups are nested, with this popup now being
>> > + the topmost popup.
>> > +
>> > + Nested popups must be destroyed in the reverse order they were created
>> > + in, e.g. the only popup you are allowed to destroy at all times is the
>> > + topmost one.
>> > +
>> > + When compositors choose to dismiss a popup, they may dismiss every
>> > + nested grabbing popup as well. When a compositor dismisses popups, it
>> > + will follow the same dismissing order as required from the client.
>> > +
>> > + If there currently is an existing popup with an explicit grab, the
>> > + parent of this popup must be that grabbing popup. The new popup will
>> > + take over the grab previously held by the current topmost grabbing
>> > + popup. If the topmost grabbing popup is destroyed, the grab will be
>> > + returned to the parent popup, if the parent popup previously had an
>> > + explicit grab.
>>
>> You're saying above that if the parent is a popup it must have an explicit grab,
>> so saying here that the grab will return to the parent only if the parent had a
>> grab before is confusing.
>
> The thing I try to explain with the above paragraph is that when a
> non-grabbing popup is the parent of a grabbing popup, for example a menu
> of a popup surface that doesn't do any grabbing, when the menu is
> dismissed, the grab should not be handed to the non grabbing popup
> surface, as it never had the grab to begin with.
But you say above:
+ The parent of a grabbing popup must either be a xdg_toplevel surface or
+ another xdg_popup with an explicit grab
So is that wrong?
>
> Do you have a suggestion on how to clarify that?
>
>>
>> > +
>> > + If the parent is a grabbing popup which has already been dismissed, this
>> > + popup will be immediately dismissed. If the parent is a popup that did
>> > + not take an explicit grab, an error will be raised.
>>
>> Can we clarify which error it is?
>
> Sure, I'll spell it out in a follow up.
>
>>
>> > +
>> > + Clients will receive events for all their surfaces during this grab
>> > + (which is an "owner-events" grab in X11 parlance). This is done so that
>> > + users can navigate through submenus and other "nested" popup windows
>> > + without having to dismiss the topmost popup.
>> > + </description>
>>
>> This doesn't explain what happens if the parent is a popup but the
>> serial and/or seat
>> passed here are different. Should it be an error? Should they be ignored?
>
> It is explained like this above:
>
>> > + If the compositor denies the grab, the popup will be immediately
>> > + dismissed.
>> > +
>> > + This request must be used in response to some sort of user action like a
>> > + button press, key press, or touch down event. The serial number of the
>> > + event should be passed as 'serial'.
>
> I'll add "The compositor may use the serial to either allow or deny the
> grab.".
>
>
> Thanks for taking a look.
>
>
> Jonas
>
>>
>> > +
>> > + <arg name="seat" type="object" interface="wl_seat"
>> > + summary="the wl_seat of the user event"/>
>> > + <arg name="serial" type="uint" summary="the serial of the user event"/>
>> > + </request>
>> > +
>> > <event name="popup_done">
>> > <description summary="popup interaction is done">
>> > The popup_done event is sent out when a popup is dismissed by the
>> > --
>> > 2.5.5
>> >
>> > _______________________________________________
>> > 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