RFC : xdg_surface_present() look-and-feel and implementation

[Manuel Bachmann]

Hello everybody,

I just updated the repo today (
https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30).
The "xdg_surface_present()" request not accepts a timestamp (uint32_t type)
as an additional parameter.

If different of 0, and it is the first time the surface should be shown,
the shell will check if a significant amount of time passed between this
timestamp and the actual present() request, and it it did, will show a
notification instead of directly mapping the surface.

You can see a demo here (1st case immediate, 2nd case delayed) :
https://www.youtube.com/watch?v=IDa2W_xMg10

The implementation is still pretty naive, but I will improve it with the
following considerations :
- if any of the application surfaces focused, or not ;
- are we on the same workspace ;
- etc.

Interested in your feedback on the protocol definition especially.


2014-07-30 0:00 GMT+02:00 Manuel Bachmann <
manuel.bachmann at open.eurogiciel.org>:

> Hi Jasper, Jason,
>
> "Agreed. Especially if you start an application, but it's slow to start,
> and you have typed into the current window or have navigated away from it
> since, you should get a popup instead of the window immediately mapped.
> This is known as "focus stealing prevention"."
>
> Good point. I will work on this.
> "Unfortunately, the protocol as Manuel mocked up doesn't have the event
> timestamp. This is required so we can track when the surface was intended
> to be presented."
>
> Have to get familiar with timestamps, looking for some useful code right
> now.
>
> "Another question for Manuel: Does present() interact with the surface
> commit? Should it?"
>
> Not in a way that I know of. From a compositor point of view, present()
> (when the user interacts to show) does only change the surface worskpace,
> stacking order, and focus. I doesn't trigger a commit, or at least it's
> unwanted. I think it can be compared to what happens when you cycle through
> windows with "Mod-Tab" and choose one.
>
>
> 2014-07-29 23:11 GMT+02:00 Jason Ekstrand <jason at jlekstrand.net>:
>
>>
>>
>>
>> On Tue, Jul 29, 2014 at 12:16 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>>
>>> On 07/29/2014 11:40 AM, Manuel Bachmann wrote:
>>>
>>>  When creating a xdg_surface, the surface will not be mapped (i.e. shown)
>>>> by desktop-shell anymore. It will only be if xdg_surface_present() has
>>>> been called once.
>>>>
>>>
>>> There seems to be a design goal in Wayland to prevent clients from
>>> making surfaces that they never map. So it would be better if creation +
>>> commit of a surface did the same thing as present. Also this does not break
>>> existing clients.
>>>
>>
>> That's the way it has worked in the past.  There's nothing requiring this
>> behavior in xdg_shell as we haven't stabilized it fully yet.  Really, it
>> doesn't matter whether the client has to call an additional request beyond
>> just creating the xdg_surface.
>>
>> Another question for Manuel: Does present() interact with the surface
>> commit?  Should it?
>>
>>
>>>
>>> There is nothing special about the first time the surface wants
>>> attention (other than historical legacy). The desktop should be allowed to
>>> turn this into a notification just like it would on subsequent calls.
>>>
>>>
>> True.  We shouldn't claim to guarantee any "window showing up behavior"
>> on the first or subsequent calls.
>>
>>
>>>
>>>  If called twice, or more, the request will send an event to
>>>> desktop-shell, so it can display a notification.
>>>>
>>>
>>> This is not controlled by a count, but by whether a window is already
>>> visible or already in the notification state. Clients should be able to
>>> send a lot of these in a row. They cannot reliably test if they are
>>> invisible and send the request only then, as there is a race condition.
>>>
>>>
>> Yes, talking about it in terms of a count is a bad plan.
>>
>>
>>> I also think the term "present" is not a great idea. This should be
>>> exactly the same as "raise" or "show" or "activate" or any number of other
>>> terms, but I have never seen the word "present" used before. I would reuse
>>> an existing term. One reason is to prevent somebody else from adding a
>>> redundant api for that term, because they did not realize "present" is the
>>> thing they are looking for.
>>>
>>
>> We also discussed the name "attention".  The reason why we didn't go with
>> "raise" or "show" is that it implies a specific action on the part of the
>> compositor, namely showing the user the window.  The term "activate" is
>> used for something else in xdg_shell so that one's out too.
>>
>> --Jason Ekstrand
>>
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>
>
> --
> 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/20140801/3a17efa3/attachment.html>