[RFC : xdg_surface_present() - take 2

Thu Apr 9 08:59:02 PDT 2015

Hi everybody again,

As there does not seem to be a great motivation to annotate the protocol,
I suppose the right way to go is to have the 2 requests.

I prepared the patches in this sense, and am going to push them for review
right now.

Regards,
Manuel

2015-03-27 6:54 GMT+01:00 Manuel Bachmann <
manuel.bachmann at open.eurogiciel.org>:

> Hi Jasper, Jonas, Pekka, Jason,
>
> Just a little update regarding the present() request. As the serial thing
> seems to be our main concern, aside from the minor protocol change and new
> functionality we mostly seem to agree on, here are the 2 ways we could do
> it :
>
> 1) modify the protocol, which means :
> - in the XML, adding : "A serial of 0 cannot be returned by the compositor
> ; thus in requests, passing 0 as a "serial" parameter actually means no
> specific serial is needed nor provided."
> - modify wayland-server to reflect the description (thanks to Jonas for
> reminding me).
>
> 2) have 2 requests instead of 1 :
> xdg_surface_present(struct xdg_surface *surface);
> xdg_surface_present_from_event(struct xdg_surface *surface, uint32_t
> serial);
>
> What should be our preferred way ? Doing 2) is still satisfying is we
> cannot do 1). Looking for a consensus here.
>
> Regards,
> Manuel
>
>
> 2015-03-09 6:17 GMT+01:00 Manuel Bachmann <
> manuel.bachmann at open.eurogiciel.org>:
>
>> 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*
>>
>
>
>
> --
> Regards,
>
>
>
> *Manuel BACHMANN Tizen Project VANNES-FR*
>

-- 
Regards,

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