<div dir="ltr"><div><div><div><div>Hi Jonas, Daniel, Derek, Bill, <br><br></div>My apologizes for the late answer, I initiallty wanted to come back Monday with a new test case, and missed some answers.<br><br></div>* Jonas, good point, I forgot to bump the protocol here. I really think it fits into xdg-shell ; what are you thinking of when you are referring to an extension ? An additional .xml ? If it can be done without breaking anything, I would be happy to push it for review.<br></div><div><br>Regarding the core of the topic - and the usefulness of these requests - my point is that :<br></div>- it is useful to desktop software (messaging IRC clients, text editors, browsers, etc..) ;<br></div>- embedded-oriented distributions, such as AGL, will definitely need it as it is a common usecase for their Wayland backends.<br><div><br><div> I wanted to showcase a heavy client such as Empathy implementing this, it unfortunately got delayed, but I'll try to have it ASAP.<br><br></div><div>* Daniels, I totally agree with you that "raise()" is a bad choice of wording, it offers false expectations, and we agreed with Jasper that present() is a lot better (plus, it resembles a "present()" function present in popular toolkits such as GTK+) ;<br><br></div><div>* Bill, Derek, about having a single request which always takes a serial argument : I initially thought the same because it seems a lot cleaner, but as no consensus was reached, and Wayland wants to position itself as a stable protocol, I think we better have the double request model for now.<br><br></div><div>Thanks a lot for your time and patience.<br></div><div><br><br></div><div><div><div><br><br></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Regards,<br><span><div><div dir="ltr"><span><font color="#888888"><div><i><small>Manuel Bachmann, Graphics Engineer<br>
<a href="http://iot.bzh" target="_blank"> www.iot.bzh</a>
</small></i></div>
</font></span><div>
</div></div></div></span><br></div></div></div>
<br><div class="gmail_quote">2015-10-02 4:07 GMT+02:00 Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Apr 09, 2015 at 06:22:53PM +0200, Manuel Bachmann wrote:<br>
> xdg_surface_present() and xdg_surface_present_from_event()<br>
> are new requests supposed to be called on an existing<br>
> xdg_surface. They tell the compositor that the surface<br>
> has new content which may be of interest to the user.<br>
> The compositor may then choose to notify the user.<br>
><br>
> xdg_surface_present_from_event() takes a serial coming<br>
> from an input (wl_keyboard, wl_pointer, wl_touch) event as<br>
> an argument. If the serial is valid and sufficiently recent,<br>
> we can suppose the new content has been issued at the user's<br>
> request ; the compositor may then choose to raise the<br>
> surface directly. Otherwise, it just behaves like present().<br>
><br>
</span>> Signed-off-by: Manuel Bachmann <<a href="mailto:manuel.bachmann@open.eurogiciel.org">manuel.bachmann@open.eurogiciel.org</a>><br>
<div><div class="h5">> ---<br>
> desktop-shell/shell.c | 15 +++++++++++++++<br>
> protocol/xdg-shell.xml | 20 ++++++++++++++++++++<br>
> 2 files changed, 35 insertions(+)<br>
><br>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c<br>
> index f7c928e..d1d3f3c 100644<br>
> --- a/desktop-shell/shell.c<br>
> +++ b/desktop-shell/shell.c<br>
> @@ -3923,6 +3923,19 @@ xdg_surface_set_minimized(struct wl_client *client,<br>
> set_minimized(shsurf->surface);<br>
> }<br>
><br>
> +static void<br>
> +xdg_surface_present(struct wl_client *client,<br>
> + struct wl_resource *resource)<br>
> +{<br>
> +}<br>
> +<br>
> +static void<br>
> +xdg_surface_present_from_event(struct wl_client *client,<br>
> + struct wl_resource *resource,<br>
> + uint32_t serial)<br>
> +{<br>
> +}<br>
> +<br>
> static const struct xdg_surface_interface xdg_surface_implementation = {<br>
> xdg_surface_destroy,<br>
> xdg_surface_set_parent,<br>
> @@ -3938,6 +3951,8 @@ static const struct xdg_surface_interface xdg_surface_implementation = {<br>
> xdg_surface_set_fullscreen,<br>
> xdg_surface_unset_fullscreen,<br>
> xdg_surface_set_minimized,<br>
> + xdg_surface_present,<br>
> + xdg_surface_present_from_event,<br>
> };<br>
><br>
> static void<br>
> diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml<br>
> index 68cf469..10f82c5 100644<br>
> --- a/protocol/xdg-shell.xml<br>
> +++ b/protocol/xdg-shell.xml<br>
> @@ -396,6 +396,26 @@<br>
> </description><br>
> </request><br>
><br>
> + <request name="present"><br>
> + <description summary="the window wants attention from the user"><br>
> + The surface has new content and would like the compositor<br>
> + to notify the user.<br>
> + </description><br>
> + </request><br>
> +<br>
> + <request name="present_from_event"><br>
> + <description summary="the window needs attention from the user"><br>
> + The surface has new content and would like the compositor<br>
> + to notify the user.<br>
> +<br>
> + If a valid and sufficiently recent serial coming from an<br>
> + input (keyboard, pointer, touch) event is passed as an<br>
> + argument, the compositor may want to raise the surface.<br>
> + Otherwise, the request just behaves like the "present" one.<br>
> + </description><br>
> + <arg name="serial" type="uint" summary="serial of an input event"/><br>
> + </request><br>
> +<br>
<br>
</div></div>This changes the protocol without bumping any versions. I'm also a bit<br>
skeptical to, at this point, doing non-essential changes to xdg_shell.<br>
Changing the experimental version is a huge pain because a version<br>
mismatch causes any mismatching client trying to use it to be<br>
terminated, without any way to discover whether it is compatible or not.<br>
Could we maybe add this as an extension to xdg_shell or something like<br>
that?<br>
<br>
<br>
Jonas<br>
<span class=""><br>
> <event name="close"><br>
> <description summary="surface wants to be closed"><br>
> The close event is sent by the compositor when the user<br>
</span>> --<br>
> 1.8.3.1<br>
<span class="">><br>
> _______________________________________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
</span><span class="">> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
</span><a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</blockquote></div><br></div>