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

[Pekka Paalanen]

On Sun, 3 Aug 2014 07:30:25 -0400
"Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> On Sun, Aug 3, 2014 at 6:27 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Fri, 1 Aug 2014 17:08:14 +0200
> > Manuel Bachmann <manuel.bachmann at open.eurogiciel.org> wrote:
> >
> > > 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.
> >
> > Like has already been said about the request name, I agree with the
> > following points:
> > - "raise" does not describe what it does
> > - "activate" does not describe what it does, activate is already
> >   related to decorations state etc. whether the window is
> >   "currently in focus" or activated, I believe.
> >
> > And I add one:
> > - "present" is confusing, because presenting means hitting the
> >   screen, and the term is heavily used in the future Presentation
> >   extension, which is on a lower level than shell.
> >
> > I think "attention" or some variation of it is perfect. A client or
> > window is requesting attention... that describes exactly what it is
> > about.
> >
> 
> I'm a bit concerned about "attention", because toolkit authors usually have
> both a "present this window" and "mark this window as needing attention"
> API. Under X11, one maps to _NET_WM_ACTIVATE and the other maps to the
> _NET_WM_STATE_DEMANDS_ATTENTION flag. This request is the former, not the
> latter. If somebody IMs me, the taskbar button might blink, but it should
> never immediately raise and show the window.
> 
> There's also on guarantee that this request will do focus-stealing or pay
> attention to the serial at all. For users that turn the behavior off, the
> window will simply pop up in front of them, and if app developers start
> using this as a non-obtrusive way of trying to gain attention, they will be
> disappointed.
> 
> I don't want to bikeshed on the list though. I'll continue to brainstorm.

Right, ACTIVATE vs. DEMANDS_ATTENTION. I assume these are two
different things in X11, as the client can simply force its way.

"Present this window" OTOH just means "map this window", and I do
not see an obvious reason why we would need that in the
Wayland protocol, as we can do the same with the first
wl_surface.commit that carries a wl_buffer. Sorry I haven't read
everything, maybe you already explained somewhere why we need a
"map/show" request? Do we have a way to hide, too?

Note, that I imagine this is different to ACTIVATE, since in my
mind activating means getting some input focus and maybe even
raising to top. Quite likely I am just confused here on what you
mean, I'm playing based on what the names sound like.

On Wayland, we cannot have "activate me now" request, we can only
have "I would like to be activated because...", and OTOH we have
the concept of demanding attention.

What is the difference between demanding attention and wishing to
be activated? I didn't see a difference, and so conflated the
concepts.

And which one was this xdg_surface_present supposed to be?

Those two questions are my confusion here.

If it is about ACTIVATE, call it something like "activate" then.

> > >    <request name="present">
> > >      <description summary="map the surface in the current context">
> > >        Calling this request on a newly-created shell surface
> > >        is mandatory to map it to the current graphical context.
> > >
> > >        If the request is called more than once, the shell will
> > >        send interactive GUI notifications, so the user can bring
> > > the surface back easily.
> > >      </description>
> > >      <arg name="serial" type="uint" summary="serial for advanced focus
> > management, can be 0"/>
> > >    </request>
> >
> > Judging from the discussion so far, I don't think should have
> > anything to do with the client mapping the surface. The compositor
> > can and should do focus stealing prevention always, and whether you
> > send one more request or not is irrelevant, also for mapping. Isn't
> > the mapping of a top-level window an implied request for attention?
> >
> 
> We currently don't have a serial or timestamp in get_xdg_surface to do
> focus-prevention stealing on, and I figured that that calling present made
> sense, since then we don't have the "map on first commit semantics".
> Instead, now we have a request for "show the window to the user".

> > You didn't document what the serial really is, where do you get
> > one, how it is used, or what it causes, and what special meaning
> > does 0 have. Note, that we explicitly define serial to not be a
> > timestamp in Wayland, they are two completely different concepts.
> >
> > Also, considering that a serial is not cross-client thing, what use
> > cases would the serial here have? Could this request be used by a
> > client to activate a top-level window B as a response to a user
> > action in its window A? Would that be in or out of scope for this
> > request?
> >
> > In the case of App1 launching App2 and using the launch-token
> > protocol I sketched in the other email, App2's top-level window
> > will already be implictly associated with App1 launching it. The
> > question there is, do we need an explicit association? Like, if you
> > can get a new serial from the launch-token in App2, you could
> > "activate" already existing windows (the Kate use case) by passing
> > that serial with attention request. Or activate several top-level
> > windows, or just one top-level window that yet was not the
> > first one created by App2.
> >
> > Anyway, these are just my ideas, and I don't know how much they
> > make sense, because I don't know how these things work currently in
> > X11. I just got the funny idea that launch-notification would be
> > related here.
> >
> 
> On X11, we have startup-notification, which is basically a hash map done as
> a sequence of add/remove broadcast ClientMessages. When you launch an app,
> you build a "startup notification" structure containing the thing you're
> launching and the event timestamp it was launched with, and send it as a
> ClientMessage. You then send the ID of that structure to the app, and when
> the app finally launches, the app broadcasts that it had launched, which
> removes the app from everybody's tracking.
> 
> The important thing is actually the middle one: telling the app what ID it
> has. This is done with the DESKTOP_STARTUP_ID envvar.
> 
> In places where startup-notification is too complicated, we have a somewhat
> silly ad-hoc convention that's not documented. You can set
> DESKTOP_STARTUP_ID to "_TIME123456", and that gives the app the event
> timestamp it was launched with, which it can use for _NET_WM_ACTIVATE and
> some other things.
> 
> We could reuse this same scheme for Wayland. Put an event serial or a event
> timestamp in DESKTOP_STARTUP_ID so it knows what to pass to the initial
> present request.

Very good, except I do not believe a timestamp is a good one (easy
to fake, does not identify anything) nor a serial (does not
identify anything, is perhaps not a global concept), so you need to
ask the server to explicitly create a cookie for you to give to
the app being launched. And if the "present" request uses a serial,
the cookie needs to be converted to serial first, or maybe rather
another "present" request that directly uses the cookie.

But I'm glad my naive thinking got to roughly the same solution you
already have in X11. :-)

Hmm, or do we not need to create any association between the
client that launches and and the client that is launched? If we
don't, then I suppose a serial would do for focus stealing
prevention, but I don't think it would work well for dismissing the
startup-notification.


Thanks,
pq