[PATCH wayland-protocols v3 6/7] xdg-shell: Make xdg_popup non-grabbing by default
Jonas Ådahl
jadahl at gmail.com
Mon Jun 13 21:53:16 UTC 2016
On Wed, Jun 08, 2016 at 11:07:46AM +0300, Giulio Camuffo wrote:
> 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?
Ah, right. We must be able to start with no explicit grab, i.e. convert
an implicit grab into an explicit grab. I suppose we should write
something like
The parent of a grabbing popup must either be another xdg_popup
with an explicit grab, or an xdg_popup or xdg_toplevel with an
implicit grab.
because we both need to be able to open up a menu from a non-grabbing
popup and a toplevel. There can't be a popup with an explicit grab if
there is any other surface with an implicit grab.
Jonas
>
> >
> > 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