[RFC : xdg_surface_present() - take 2

Sun Mar 8 19:25:32 PDT 2015

On Sun, Mar 8, 2015 at 6:57 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

> On Fri, Feb 27, 2015 at 11:14:19AM +0100, Manuel Bachmann wrote:
> > 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.
>
> I have some comments I thought I'd share. See the inline replies:
>
> >
> > 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 ;
>
> There is also the "The Present Extension" in X11, so is "present" really
> that much better? If the use case is a client wants attention because
> some reason (be it IRC highlight, new message, task finished or
> whatever), shouldn't the request name contain that information some how?
> Isn't what is discussed here even quite similar to
> "_NET_WM_STATE_DEMANDS_ATTENTION"?
>

No. It's equivalent to the _NET_ACTIVATE_WINDOW ClientMessage.

IRC highlights, new messages, task finished, etc. are use cases for
notifications. The use case here is "user double-clicked on a file and I
want my existing gedit window to be raised in response". Basically, places
where you want to show the window immediately if the stars are aligned
correctly (the serial is correct).

> >
> > - 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 ;
>
> This rather sound like something startup notification protocol related
> than an "I need attention" request, and I think that problem needs to be
> tackled separately.
>

This is not an "I need attention" request. Perhaps our documentation is
poor.

> >
> > - 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 ;
>
> As Bill mentioned, clients that happens to do a lot of things before
> connecting will have a very short time from that the connection is
> established to that a surface is to be mapped. It can even be trivially
> abused to steal focus at unexpected times.
>
> >
> > - 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.
>
> Serials are quite easy to guess, but for intra-client focus switching it
> might work. I don't think it's a good idea to pass serials between
> clients and assume they have any effect, and the server should probably
> not allow such focus switching between clients.
>
> >
> > 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 ?
>
> If 0-is-invalid its not formalized, it should not be relied upon IMO,
> but I think it is useful to have a non-valid serial.
>
>
> Jonas
>
> >
> > (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*
>
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150308/adf16320/attachment.html>