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

[Pekka Paalanen]

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.

>    <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?

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.


Thanks,
pq