On Wed, Jun 08, 2016 at 11:07:46AM +0300, Giulio Camuffo wrote: > 2016-06-08 3:08 GMT+02:00 Jonas Ådahl <jad...@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 <jad...@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 <jad...@gmail.com> > >> > Signed-off-by: Mike Blumenkrantz <zm...@samsung.com> > >> > Reviewed-by: Yong Bakos <yba...@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@lists.freedesktop.org > >> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel