[RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

Hello fellow developers,

I just wanted to continue a discussion which occured some time ago, about
the eventuality of adding a "xdg_surface_present()" request to XDG-Shell.

(For reference, former discussion entry points are here :
http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html
http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html
http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html)

To summarize : the idea behing "xdg_surface_present()" is that there are
some cases where a surface wants to advertise the fact that it has been
updated and the user may want to take a look (think of an IRC chat window
which gets new messages containing the user's nickname). There are even
some corner cases where the surface may want to be raised and focused
directly ; but we do not want to request to be abused this way, a client
must be prevented from stealing the focus repeatedly. At last, the
compositor's shell should have the last word.

Here are some of the points that were discussed and the outcomes :

- Pekka Paalanen pointed out the request name was unclear and suggested to
use "xdg_surface_needs/wants_attention()" instead. Jasper St. Pierre
pointed out that "_NET_WM_STATE_DEMANDS_ATTENTION" already existed in X11
and does not do the same thing. We discussed that again yesterday and
thought that present() fitted nicely ;

- We want to implement focus stealing prevention : if the user is starting
a slow app (browser...), gets back to typing a mail while it starts, and at
last the browser window appears, the focus should stay in the mail window
without his keyboard presses going elsewhere ;

- Implementing focus stealing prevention between different clients may be
easy : just count the delay between the client has been started and its
shell surface actually gets mapped, and if it has been too long and the
focus is elsewhere, show the surface without focusing it (but with a
notification). The notion of "the client has been started" is vague, but at
worst, we can use the time when the client did its initial connection to
the compositor ;

- Within a same client application, however, it is harder. Think of a
browser where you click "new window" but lots of time pass before it
appears. The "starting point" is the pointer click event. So the idea would
be to pass the Wayland serial corresponding to this event :
"xdg_surface_present (surface, <SERIAL>)". It the serial has been issued
too long ago, do focus stealing prevention.

This raises the question : how do we say "We have no serial to pass", for
the standard case ? We repeatedly suggested 0 ("xdg_surface_present
(surface, 0)") because serials are incrementing globals, so "0" to be
issued would be very-very unlikely. Should we formalize that somewhere in
the protocol ?

(Having 2 requests, one with serial and one without, has been suggested by
krh on IRC ; I personally prefer only one request because they would serve
the same purpose, but why not ? It would get the need for formalization out
of the way)

We also want to secure the request from garbage random serials ; the
implementation behavior is that there is only one serial valid for a few
seconds, if the surface has not been focused for some time, it will not be
able to raise itself even if it random()ly finds the formerly "good" serial.

-----
Now the demos ! Here is the latest code :

https://github.com/Tarnyko/weston-xdg_surface_present/commits/test

A video for the generic "focus stealing prevention" case (delayed start,
focus stays in old surface) between different clients :

https://www.youtube.com/watch?v=gifjXyPV3X4

and within the same client :

https://www.youtube.com/watch?v=Xiq1p5AOf1U
-----

Any thoughts on this ?

-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150227/6875ce72/attachment.html>