[RFC : xdg_surface_present() - take 2

Sun Mar 8 22:17:19 PDT 2015

Hi Jasper,

"This is not an "I need attention" request. Perhaps our documentation is
poor."
You are right, just as I answered to Jonas, I mixed present() with the
desktop-launcher-focus-stealing feature we were discussing in the previous
thread. Sorry for the confusion.

2015-03-09 3:25 GMT+01:00 Jasper St. Pierre <jstpierre at mecheye.net>:

>
>
> 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
>

-- 
Regards,

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