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

Sun Aug 3 04:30:25 PDT 2014

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.

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

> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140803/b301af76/attachment-0001.html>