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

[Manuel Bachmann]

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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140730/45bb19dd/attachment.html>