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

[Jason Ekstrand]

On Tue, Jul 29, 2014 at 3:00 PM, Manuel Bachmann <
manuel.bachmann at open.eurogiciel.org> wrote:

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

Given that it's not supposed to be directly tied to a specific compositor
action, that's probably best.  I just wanted to make sure you were thinking
about this and had a reason.
--Jason


>
>
> 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/20140729/d6003994/attachment.html>