<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 3, 2014 at 6:27 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On Fri, 1 Aug 2014 17:08:14 +0200<br> Manuel Bachmann <<a href="mailto:manuel.bachmann@open.eurogiciel.org">manuel.bachmann@open.eurogiciel.org</a>> wrote:<br> <br> > Hello everybody,<br> ><br> > I just updated the repo today (<br> > <a href="https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30" target="_blank">https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30</a>).<br> > The "xdg_surface_present()" request not accepts a timestamp (uint32_t type)<br> > as an additional parameter.<br> ><br> > If different of 0, and it is the first time the surface should be shown,<br> > the shell will check if a significant amount of time passed between this<br> > timestamp and the actual present() request, and it it did, will show a<br> > notification instead of directly mapping the surface.<br> ><br> > You can see a demo here (1st case immediate, 2nd case delayed) :<br> > <a href="https://www.youtube.com/watch?v=IDa2W_xMg10" target="_blank">https://www.youtube.com/watch?v=IDa2W_xMg10</a><br> ><br> > The implementation is still pretty naive, but I will improve it with the<br> > following considerations :<br> > - if any of the application surfaces focused, or not ;<br> > - are we on the same workspace ;<br> > - etc.<br> ><br> > Interested in your feedback on the protocol definition especially.<br> <br> </div>Like has already been said about the request name, I agree with the<br> following points:<br> - "raise" does not describe what it does<br> - "activate" does not describe what it does, activate is already<br> related to decorations state etc. whether the window is<br> "currently in focus" or activated, I believe.<br> <br> And I add one:<br> - "present" is confusing, because presenting means hitting the<br> screen, and the term is heavily used in the future Presentation<br> extension, which is on a lower level than shell.<br> <br> I think "attention" or some variation of it is perfect. A client or<br> window is requesting attention... that describes exactly what it is<br> about.<br></blockquote><div><br></div><div>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.<br> <br></div><div>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.<br> <br></div><div>I don't want to bikeshed on the list though. I'll continue to brainstorm.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > <request name="present"><br> > <description summary="map the surface in the current context"><br> > Calling this request on a newly-created shell surface<br> > is mandatory to map it to the current graphical context.<br> ><br> > If the request is called more than once, the shell will<br> > send interactive GUI notifications, so the user can bring<br> > the surface back easily.<br> > </description><br> > <arg name="serial" type="uint" summary="serial for advanced focus management, can be 0"/><br> > </request><br> <br> Judging from the discussion so far, I don't think should have<br> anything to do with the client mapping the surface. The compositor<br> can and should do focus stealing prevention always, and whether you<br> send one more request or not is irrelevant, also for mapping. Isn't<br> the mapping of a top-level window an implied request for attention?<br></blockquote><div><br></div><div>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".<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> You didn't document what the serial really is, where do you get<br> one, how it is used, or what it causes, and what special meaning<br> does 0 have. Note, that we explicitly define serial to not be a<br> timestamp in Wayland, they are two completely different concepts.<br> <br> Also, considering that a serial is not cross-client thing, what use<br> cases would the serial here have? Could this request be used by a<br> client to activate a top-level window B as a response to a user<br> action in its window A? Would that be in or out of scope for this<br> request?<br> <br> In the case of App1 launching App2 and using the launch-token<br> protocol I sketched in the other email, App2's top-level window<br> will already be implictly associated with App1 launching it. The<br> question there is, do we need an explicit association? Like, if you<br> can get a new serial from the launch-token in App2, you could<br> "activate" already existing windows (the Kate use case) by passing<br> that serial with attention request. Or activate several top-level<br> windows, or just one top-level window that yet was not the<br> first one created by App2.<br> <br> Anyway, these are just my ideas, and I don't know how much they<br> make sense, because I don't know how these things work currently in<br> X11. I just got the funny idea that launch-notification would be<br> related here.<br></blockquote><div><br></div><div>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.<br> <br>The important thing is actually the middle one: telling the app what ID it has. This is done with the DESKTOP_STARTUP_ID envvar.<br><br>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.<br> <br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Thanks,<br> pq<br> <div class=""><div class="h5">_______________________________________________<br> wayland-devel mailing list<br> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br> </div></div></blockquote></div><br><br clear="all"><br>-- <br> Jasper<br> </div></div>