On Wed, 30 Jul 2014 00:00:37 +0200 Manuel Bachmann <manuel.bachm...@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. No, timestamp at least is the wrong thing. We do not use timestamps in wayland for tracking actions, because they are easily faked. You cannot rely on the clock incrementing every time you need a new token, which means you cannot guarantee ordering always. You also cannot know how much the increment is from the previous. I completely agree with what Jason said to Jasper in IRC recently, that serials should be used instead. The compositor can bump the serial exactly when appropriate and there is no need for heuristics of how long is too long. Users can be fast or slow to get bored and switch apps. Whether you want to key off the input event serials or have a new one in xdg_shell, I cannot say. However, I have one thing to add. I'm not sure if serials are global. Are they? Should they be? Maybe not. We have an outstanding issue of how to tell the compositor when a client is launching another client. This requires the new client to identify itself somehow, so that the compositor knows this is caused by the old client. Focus stealing prevention needed something like this and maybe something else needed it, too, right? This will probably require defining a standard way to pass a token from the old client to the new client, so that the new client can identify to the compositor why it was being launched. Even if serials in xdg_shell were global, they would not be enough, because it cannot identify the source, the old client. It seems that the old client needs a way to ask the compositor to create a launch token (this can be associated with an xdg_shell serial if needed, and the serial does not need to be global), pass the launch token to the new client (via some standard env?), and the new client will pass the token to the compositor again. This creates a link for the old client launching the new client. Then you can do what is best. Does this make any sense, and did X11 already have something like this? I suppose getting the token could be associated with a launch notifier in the DE or what it is. What I wrote above is almost completely unrelated to the attention request, so the attention request might not need to take this into account at all. If the new client presents a current token, the attention request could simply be acted on by raising and activating the window. (Wait... which window?) That's just some of my mind flow, not a serious request "you should do this". :-) > "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. The only question I can think of there is, can a window demand attention if it is not mapped? Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel