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

[Pekka Paalanen]

On Wed, 30 Jul 2014 00:00:37 +0200
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.

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