On Tue, Jul 29, 2014 at 3:00 PM, Manuel Bachmann < [email protected]> 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 <[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* >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
