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 < [email protected]>: > 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 <[email protected]>: > >> >> >> >> On Tue, Jul 29, 2014 at 12:16 PM, Bill Spitzak <[email protected]> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >> > > > -- > Regards, > > > > *Manuel BACHMANN Tizen Project VANNES-FR* > -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR*
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
