Re: [PATCH wayland v2] client: Fully flush during blocking dispatch

[Jonas Ådahl]

On Tue, Jan 12, 2016 at 10:01:17AM +, Daniel Stone wrote:
> On 12 January 2016 at 04:31, Jonas Ådahl  wrote:
> > wl_display_flush() may fail with EAGAIN which means that not all data
> > waiting in the buffer has been flushed. We later block until there
> > data to read, which could mean that we block on input from the
> > compositor without having sent out all data from the client. Avoid this
> > by fully flushing the socket before starting to wait.
> >
> > Signed-off-by: Jonas Ådahl 
> 
> Biting my tongue on a coding-style bikeshed.

For the record, I dug out the shed color, and did some paint shade
changes. This series is now pushed:

   da7b248..c643781  master -> master


Jonas


> 
> Reviewed-by: Daniel Stone 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 2/2] protocol: Add DnD actions

[Jonas Ådahl]

On Fri, Jan 15, 2016 at 02:49:33PM -0800, Bryce Harrington wrote:
> On Fri, Jan 15, 2016 at 09:11:40PM +0100, Carlos Garnacho wrote:
> > These 2 requests have been added:
> > 
> > - wl_data_source.set_actions: Notifies the compositor of the available
> >   actions on the data source.
> > - wl_data_offer.set_actions: Notifies the compositor of the available
> >   actions on the destination side, plus the preferred action.
> > 
> > Out of the data from these requests, the compositor can determine the action
> > both parts agree on (and let the user play a role through eg. keyboard
> > modifiers). The chosen option will be notified to both parties
> > through the following two requests:
> > 
> > - wl_data_source.action
> > - wl_data_offer.action
> > 
> > In addition, the destination side can peek the source side actions through
> > wl_data_offer.source_actions.
> > 
> > Compared to the XDND protocol, there's two notable changes:
> > 
> > - XDND lets the source suggest an action, whereas wl_data_device lets
> >   the destination prefer a given action. The difference is subtle here,
> >   it comes off as convenience because it is the drag destination which
> >   receives the motion events (unlike in X) and can perform action updates.
> > 
> >   The drag destination seems also in a better position to update the
> >   preferred action based on things like the data being transferred, the
> >   place being dropped, and whether the drag is client-local.
> > 
> > - That same source-side preferred action is used in XDND to convey the
> >   modifier-induced action to the drag destination, which would then ack
> >   it, or reply with another action that's accepted (or none), this makes
> >   the XdndPosition/XdndStatus messaging very verbose, and synchronous
> >   because the drag source always needs to know the latest status/action
> >   for every position+action sent.
> > 
> >   Here it's the compositor which takes care of modifiers and matching
> >   available/accepted actions, this allows for the signaling to happen
> >   only whenever the actions/modifiers change for real.
> > 
> > Roughly based on previous work by Giulio Camuffo 
> > 
> > Changes since v10:
> > - Narrow down the situations where wl_data_source/offer.accept requests
> >   are supposed to happen.
> > 
> > Changes since v9:
> > - Deferred the protocol errors to .finish after some IRC chat with Jonas,
> >   added further errors if actions API is used on selection sources/offers.
> > 
> > Changes since v8:
> > - Defined further the expected behavior on "ask", described the protocol
> >   errors that may happen. Fix more spaces vs tabs issues.
> > 
> > Changes since v7:
> > - Misc changes after updating the progress notification patch.
> > 
> > Changes since v6:
> > - Further explanations on wl_data_source/offer.set_actions, including a
> >   description of "ask" actions. Added protocol errors for unknown action
> >   values.
> > 
> > Changes since v5:
> > - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
> >   scheme for actions. Fixed indentation and other minor formatting issues.
> > 
> > Changes since v4:
> > - Minor rewording.
> > 
> > Changes since v3:
> > - Splitted from DnD progress notification changes.
> > - Further rationales in commit log.
> > 
> > Changes since v2:
> > - Renamed notify_actions to set_actions on both sides, seems more consistent
> >   with the rest of the protocol.
> > - Spelled out better which events may be triggered on the compositor side
> >   by the requests, the circumstances in which events are emitted, and
> >   what are events useful for in clients.
> > - Defined a minimal common ground wrt compositor-side action picking and
> >   keybindings.
> > - Acknowledge the possibility of compositor/toolkit defined actions, even
> >   though none are used at the moment.
> > Changes since v1:
> > - Added wl_data_offer.source_actions to let know of the actions offered
> >   by a data source.
> > - Renamed wl_data_source.finished to "drag_finished" for clarity
> > - Improved wording as suggested by Bryce
> > 
> > Signed-off-by: Carlos Garnacho 
> > Reviewed-by: Michael Catanzaro 
> > Reviewed-by: Mike Blumenkrantz 
> > Reviewed-by: Jonas Ådahl 
> 
> Reviewed-by: Bryce Harrington 

I have now landed the two protocol patches after having fixed the grammar
nitpicks. Carlos, it'd be good if you could just double check I did the
right choices where there were options.

I'm waiting with the weston patches until Monday or so, so they can get
some more review.


Jonas

> 
> (Again, optional grammar nitpicks below, ok to land as follow up post-alpha.)
> 
> > ---
> >  protocol/wayland.xml | 205 
> > ++-
> >  1 file changed, 204 insertions(+), 1 deletion(-)
> > 
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 

Re: [PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

Hi Jonas!

On Sat, Jan 16, 2016 at 9:37 AM, Jonas Ådahl  wrote:
> On Fri, Jan 15, 2016 at 02:49:33PM -0800, Bryce Harrington wrote:
>> On Fri, Jan 15, 2016 at 09:11:40PM +0100, Carlos Garnacho wrote:
>> > These 2 requests have been added:
>> >
>> > - wl_data_source.set_actions: Notifies the compositor of the available
>> >   actions on the data source.
>> > - wl_data_offer.set_actions: Notifies the compositor of the available
>> >   actions on the destination side, plus the preferred action.
>> >
>> > Out of the data from these requests, the compositor can determine the 
>> > action
>> > both parts agree on (and let the user play a role through eg. keyboard
>> > modifiers). The chosen option will be notified to both parties
>> > through the following two requests:
>> >
>> > - wl_data_source.action
>> > - wl_data_offer.action
>> >
>> > In addition, the destination side can peek the source side actions through
>> > wl_data_offer.source_actions.
>> >
>> > Compared to the XDND protocol, there's two notable changes:
>> >
>> > - XDND lets the source suggest an action, whereas wl_data_device lets
>> >   the destination prefer a given action. The difference is subtle here,
>> >   it comes off as convenience because it is the drag destination which
>> >   receives the motion events (unlike in X) and can perform action updates.
>> >
>> >   The drag destination seems also in a better position to update the
>> >   preferred action based on things like the data being transferred, the
>> >   place being dropped, and whether the drag is client-local.
>> >
>> > - That same source-side preferred action is used in XDND to convey the
>> >   modifier-induced action to the drag destination, which would then ack
>> >   it, or reply with another action that's accepted (or none), this makes
>> >   the XdndPosition/XdndStatus messaging very verbose, and synchronous
>> >   because the drag source always needs to know the latest status/action
>> >   for every position+action sent.
>> >
>> >   Here it's the compositor which takes care of modifiers and matching
>> >   available/accepted actions, this allows for the signaling to happen
>> >   only whenever the actions/modifiers change for real.
>> >
>> > Roughly based on previous work by Giulio Camuffo 
>> >
>> > Changes since v10:
>> > - Narrow down the situations where wl_data_source/offer.accept requests
>> >   are supposed to happen.
>> >
>> > Changes since v9:
>> > - Deferred the protocol errors to .finish after some IRC chat with Jonas,
>> >   added further errors if actions API is used on selection sources/offers.
>> >
>> > Changes since v8:
>> > - Defined further the expected behavior on "ask", described the protocol
>> >   errors that may happen. Fix more spaces vs tabs issues.
>> >
>> > Changes since v7:
>> > - Misc changes after updating the progress notification patch.
>> >
>> > Changes since v6:
>> > - Further explanations on wl_data_source/offer.set_actions, including a
>> >   description of "ask" actions. Added protocol errors for unknown action
>> >   values.
>> >
>> > Changes since v5:
>> > - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
>> >   scheme for actions. Fixed indentation and other minor formatting issues.
>> >
>> > Changes since v4:
>> > - Minor rewording.
>> >
>> > Changes since v3:
>> > - Splitted from DnD progress notification changes.
>> > - Further rationales in commit log.
>> >
>> > Changes since v2:
>> > - Renamed notify_actions to set_actions on both sides, seems more 
>> > consistent
>> >   with the rest of the protocol.
>> > - Spelled out better which events may be triggered on the compositor side
>> >   by the requests, the circumstances in which events are emitted, and
>> >   what are events useful for in clients.
>> > - Defined a minimal common ground wrt compositor-side action picking and
>> >   keybindings.
>> > - Acknowledge the possibility of compositor/toolkit defined actions, even
>> >   though none are used at the moment.
>> > Changes since v1:
>> > - Added wl_data_offer.source_actions to let know of the actions offered
>> >   by a data source.
>> > - Renamed wl_data_source.finished to "drag_finished" for clarity
>> > - Improved wording as suggested by Bryce
>> >
>> > Signed-off-by: Carlos Garnacho 
>> > Reviewed-by: Michael Catanzaro 
>> > Reviewed-by: Mike Blumenkrantz 
>> > Reviewed-by: Jonas Ådahl 
>>
>> Reviewed-by: Bryce Harrington 
>
> I have now landed the two protocol patches after having fixed the grammar
> nitpicks. Carlos, it'd be good if you could just double check I did the
> right choices where there were options.

Yay! Thanks for doing that. Checking the diff everything looked great,
only spotted one thing that eluded reviews in the last paragraph of
wl_data_offer.action:

+   may potentially choose different a different action and/or mime type,

Re: [PATCH weston 2/5] data-device: Implement DnD actions

[Jonas Ådahl]

On Fri, Jan 15, 2016 at 09:14:24PM +0100, Carlos Garnacho wrote:
> The policy in weston in order to determine the chosen DnD action is
> deliberately simple, and is probably the minimals that any compositor
> should be doing here.
> 
> Besides honoring the set_actions requests on both wl_data_source and
> wl_data_offer, weston now will emit the newly added "action" events
> notifying both source and dest of the chosen action.
> 
> The "dnd" client has been updated too (although minimally), so it
> notifies the compositor of a "move" action on both sides.
> 
> Changes since v7:
>   - Fixes spotted during review. Add client-side version checks.
> Implement .action emission as specified in protocol patch v11.
> 
> Changes since v6:
>   - Emit errors as defined in DnD actions patch v10.
> 
> Changes since v5:
>   - Use enum types and values for not-a-bitfield stored values.
> handle errors when finding unexpected dnd_actions values.
> 
> Changes since v4:
>   - Added compositor-side version checks. Spaces vs tabs fixes.
> Fixed resource versioning. Initialized new weston_data_source/offer
> fields.
> 
> Changes since v3:
>   - Put data_source.action to use in the dnd client, now updates
> the dnd surface like data_source.target events do.
> 
> Changes since v2:
>   - Split from DnD progress notification changes.
> 
> Changes since v1:
>   - Updated to v2 of DnD actions protocol changes, implement
> wl_data_offer.source_actions.
>   - Fixed coding style issues.
> 
> Signed-off-by: Carlos Garnacho 
> Reviewed-by: Michael Catanzaro 

Except for couple of minor issues and a couple of nits, this patch is
now  Reviewed-by: Jonas Ådahl .

> ---
>  clients/dnd.c |  36 ++--
>  clients/window.c  |  34 +++
>  clients/window.h  |   3 +
>  src/compositor.h  |   6 ++
>  src/data-device.c | 172 
> --
>  5 files changed, 242 insertions(+), 9 deletions(-)
> 
> diff --git a/clients/dnd.c b/clients/dnd.c
> index 974429b..d32655d 100644
> --- a/clients/dnd.c
> +++ b/clients/dnd.c
> @@ -72,6 +72,7 @@ struct dnd_drag {
>   struct item *item;
>   int x_offset, y_offset;
>   int width, height;
> + uint32_t dnd_action;
>   const char *mime_type;
>  
>   struct wl_surface *drag_surface;
> @@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
>  }
>  
>  static void
> -data_source_target(void *data,
> -struct wl_data_source *source, const char *mime_type)
> +dnd_drag_update_surface(struct dnd_drag *dnd_drag)
>  {
> - struct dnd_drag *dnd_drag = data;
>   struct dnd *dnd = dnd_drag->dnd;
>   cairo_surface_t *surface;
>   struct wl_buffer *buffer;
>  
> - dnd_drag->mime_type = mime_type;
> - if (mime_type)
> + if (dnd_drag->mime_type && dnd_drag->dnd_action)
>   surface = dnd_drag->opaque;
>   else
>   surface = dnd_drag->translucent;
> @@ -288,6 +286,16 @@ data_source_target(void *data,
>  }
>  
>  static void
> +data_source_target(void *data,
> +struct wl_data_source *source, const char *mime_type)
> +{
> + struct dnd_drag *dnd_drag = data;
> +
> + dnd_drag->mime_type = mime_type;
> + dnd_drag_update_surface(dnd_drag);
> +}
> +
> +static void
>  data_source_send(void *data, struct wl_data_source *source,
>const char *mime_type, int32_t fd)
>  {
> @@ -360,12 +368,22 @@ data_source_dnd_finished(void *data, struct 
> wl_data_source *source)
>   dnd_drag_destroy(dnd_drag);
>  }
>  
> +static void
> +data_source_action(void *data, struct wl_data_source *source, uint32_t 
> dnd_action)
> +{
> + struct dnd_drag *dnd_drag = data;
> +
> + dnd_drag->dnd_action = dnd_action;
> + dnd_drag_update_surface(dnd_drag);
> +}
> +
>  static const struct wl_data_source_listener data_source_listener = {
>   data_source_target,
>   data_source_send,
>   data_source_cancelled,
>   data_source_dnd_drop_performed,
>   data_source_dnd_finished,
> + data_source_action,
>  };
>  
>  static cairo_surface_t *
> @@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
>   dnd_drag->item = item;
>   dnd_drag->x_offset = x - item->x;
>   dnd_drag->y_offset = y - item->y;
> + dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
> + dnd_drag->mime_type = NULL;
>  
>   for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
>   if (item == dnd->items[i]){
> @@ -456,6 +476,12 @@ create_drag_source(struct dnd *dnd,
>text_mime_type);
>   }
>  
> + if (display_get_data_device_manager_version(display) >=
> + WL_DATA_SOURCE_SET_ACTIONS_SINCE_VERSION) {
> + wl_data_source_set_actions(dnd_drag->data_source,
> +   

Re: [PATCH wayland-protocols 3/3] xdg-shell: Introduce xdg_tooltip

[Mike Blumenkrantz]

On Sat, 16 Jan 2016 10:28:20 +0800
Jonas Ådahl  wrote:

> On Fri, Jan 15, 2016 at 09:19:34PM -0500, Mike Blumenkrantz wrote:
> > Hi,
> > 
> > I have some suggestions which I've inlined below:
> > 
> > On Tue, 12 Jan 2016 16:16:49 +0800
> > Jonas Ådahl  wrote:
> >   
> > > An xdg_tooltip is a new window type used to implement tooltip like
> > > surfaces. See the interface documentation for details.
> > > 
> > > Signed-off-by: Jonas Ådahl 
> > > ---
> > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 47 
> > > 
> > >  1 file changed, 47 insertions(+)
> > > 
> > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > index 276d9fc..91f657a 100644
> > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > @@ -183,6 +183,23 @@
> > >
> > >  
> > >  
> > > +
> > > +  
> > > + This creates an xdg_tooltip for the given xdg_surface and gives the
> > > + associated wl_surface the xdg_tooltip role. A wl_surface can only have
> > > + one xdg_tooltip role. If the wl_surface is given the xdg_tooltip role
> > > + while it already has an active xdg_tooltip role, or if it has been given
> > > + any other role before, an error is raised.  
> > 
> > I think my comment on the first patch proves its relevance here as this 
> > section could
> > be greatly shortened by specifying singular surface role semantics in 
> > xdg_surface.
> >   
> > > +
> > > + See the documentation of xdg_tooltip for more details about what an
> > > + xdg_tooltip is and how it is used.
> > > +  
> > > +  
> > > +  
> > > +  
> > > +  
> > > +
> > > +
> > >  
> > >
> > >   The window geometry of a surface is its "visible bounds" from the
> > > @@ -666,4 +683,34 @@
> > >  
> > >
> > >  
> > > +  
> > > +
> > > +  This interface defines an xdg_tooltip role that provides 
> > > functionality
> > > +  related to tooltip like surfaces.
> > > +
> > > +  An xdg_tooltip is temporary a surface that is part of another 
> > > xdg_surface
> > > +  (such as xdg_toplevel or xdg_popup) such as a tooltip above a UI 
> > > widget. It
> > > +  will always be mapped above both its parent and if the parent has a
> > > +  xdg_popup child it will also be mapped above that and all other 
> > > possible
> > > +  chained xdg_popup surfaces.  
> > 
> > "An xdg_tooltip is a temporary surface which is displayed over its parent 
> > xdg_surface.
> > The last-created xdg_tooltip surface will always be the top-most child of 
> > the parent xdg_surface."
> >   
> > > +
> > > +  The parent surface must either have the surface role xdg_toplevel,
> > > +  xdg_popup or xdg_tooltip.
> > > +
> > > +  Being different from xdg_popup, it does not take an active grab 
> > > while
> > > +  being mapped, and it will never be automatically dismissed by any
> > > +  predefined user interaction. The client must itself unmap it using 
> > > the
> > > +  xdg_tooltip.destroy request.  
> > 
> > Wouldn't it be enough to have
> > 
> > "An xdg_tooltip does not take an active grab while mapped. xdg_tooltip 
> > surfaces are
> > either directly unmapped by clients using the xdg_tooltip.destroy request 
> > or indirectly
> > unmapped when their parent surface is unmapped."
> >   
> > > +
> > > +  An xdg_tooltip can receive input assuming it has an input region.  
> > 
> > "An xdg_tooltip obeys normal input region semantics." or similar ?
> >   
> > > +
> > > +  If for some reason its parent is unmapped, for example if the 
> > > parent is a
> > > +  popup being dismissed, the tooltip will be unmapped as well.  
> > 
> > I think this is now covered a few lines up?  
> 
> Hmm. You mean about "always be made top-most child"? It doesn't make it
> clear what happens if the parent is unmapped though.

I'm not sure exactly what you mean by this. I think stating that a tooltip will 
be
"unmapped when their parent surface is unmapped" is fairly clear, no?

> 
> Other comments makes sense though, will fix.
> 
> 
> Jonas
> 
> >   
> > > +
> > > +
> > > +
> > > +  Unmap the tooltip surface and destroy the object.
> > > +
> > > +  
> > > +
> > >
> >   
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/3] xdg-shell: Introduce xdg_tooltip

[Jonas Ådahl]

On Sat, Jan 16, 2016 at 03:07:00PM -0500, Mike Blumenkrantz wrote:
> On Sat, 16 Jan 2016 10:28:20 +0800
> Jonas Ådahl  wrote:
> 
> > On Fri, Jan 15, 2016 at 09:19:34PM -0500, Mike Blumenkrantz wrote:
> > > Hi,
> > > 
> > > I have some suggestions which I've inlined below:
> > > 
> > > On Tue, 12 Jan 2016 16:16:49 +0800
> > > Jonas Ådahl  wrote:
> > >   
> > > > An xdg_tooltip is a new window type used to implement tooltip like
> > > > surfaces. See the interface documentation for details.
> > > > 
> > > > Signed-off-by: Jonas Ådahl 
> > > > ---
> > > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 47 
> > > > 
> > > >  1 file changed, 47 insertions(+)
> > > > 
> > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > index 276d9fc..91f657a 100644
> > > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > @@ -183,6 +183,23 @@
> > > >
> > > >  
> > > >  
> > > > +
> > > > +  
> > > > +   This creates an xdg_tooltip for the given xdg_surface and gives 
> > > > the
> > > > +   associated wl_surface the xdg_tooltip role. A wl_surface can 
> > > > only have
> > > > +   one xdg_tooltip role. If the wl_surface is given the 
> > > > xdg_tooltip role
> > > > +   while it already has an active xdg_tooltip role, or if it has 
> > > > been given
> > > > +   any other role before, an error is raised.  
> > > 
> > > I think my comment on the first patch proves its relevance here as this 
> > > section could
> > > be greatly shortened by specifying singular surface role semantics in 
> > > xdg_surface.
> > >   
> > > > +
> > > > +   See the documentation of xdg_tooltip for more details about 
> > > > what an
> > > > +   xdg_tooltip is and how it is used.
> > > > +  
> > > > +  
> > > > +  
> > > > +  
> > > > +  
> > > > +
> > > > +
> > > >  
> > > >
> > > > The window geometry of a surface is its "visible bounds" from 
> > > > the
> > > > @@ -666,4 +683,34 @@
> > > >  
> > > >
> > > >  
> > > > +  
> > > > +
> > > > +  This interface defines an xdg_tooltip role that provides 
> > > > functionality
> > > > +  related to tooltip like surfaces.
> > > > +
> > > > +  An xdg_tooltip is temporary a surface that is part of another 
> > > > xdg_surface
> > > > +  (such as xdg_toplevel or xdg_popup) such as a tooltip above a UI 
> > > > widget. It
> > > > +  will always be mapped above both its parent and if the parent 
> > > > has a
> > > > +  xdg_popup child it will also be mapped above that and all other 
> > > > possible
> > > > +  chained xdg_popup surfaces.  
> > > 
> > > "An xdg_tooltip is a temporary surface which is displayed over its parent 
> > > xdg_surface.
> > > The last-created xdg_tooltip surface will always be the top-most child of 
> > > the parent xdg_surface."
> > >   
> > > > +
> > > > +  The parent surface must either have the surface role 
> > > > xdg_toplevel,
> > > > +  xdg_popup or xdg_tooltip.
> > > > +
> > > > +  Being different from xdg_popup, it does not take an active grab 
> > > > while
> > > > +  being mapped, and it will never be automatically dismissed by any
> > > > +  predefined user interaction. The client must itself unmap it 
> > > > using the
> > > > +  xdg_tooltip.destroy request.  
> > > 
> > > Wouldn't it be enough to have
> > > 
> > > "An xdg_tooltip does not take an active grab while mapped. xdg_tooltip 
> > > surfaces are
> > > either directly unmapped by clients using the xdg_tooltip.destroy request 
> > > or indirectly
> > > unmapped when their parent surface is unmapped."
> > >   
> > > > +
> > > > +  An xdg_tooltip can receive input assuming it has an input 
> > > > region.  
> > > 
> > > "An xdg_tooltip obeys normal input region semantics." or similar ?
> > >   
> > > > +
> > > > +  If for some reason its parent is unmapped, for example if the 
> > > > parent is a
> > > > +  popup being dismissed, the tooltip will be unmapped as well.  
> > > 
> > > I think this is now covered a few lines up?  
> > 
> > Hmm. You mean about "always be made top-most child"? It doesn't make it
> > clear what happens if the parent is unmapped though.
> 
> I'm not sure exactly what you mean by this. I think stating that a tooltip 
> will be
> "unmapped when their parent surface is unmapped" is fairly clear, no?

I mean that the only place that adds "unmapped when their parent surface
is unmapped" is that paragraph. Maybe changing it to "An xdg_tooltip
surface will also be automatically unmapped if the parent surface is
unmapped."?


Jonas

> 
> > 
> > Other comments makes sense though, will fix.
> > 
> > 
> > Jonas
> > 
> > >   
> > > > +
> > > > +
> > > > +
> > > > +  Unmap the tooltip surface and destroy