<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 3, 2014 at 8:43 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=""><div class="h5">On Sun, 3 Aug 2014 07:30:25 -0400<br> "Jasper St. Pierre" <<a href="mailto:jstpierre@mecheye.net">jstpierre@mecheye.net</a>> wrote:<br> <br> > On Sun, Aug 3, 2014 at 6:27 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br> ><br> > > 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> > > ><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> > > ).<br> > > > The "xdg_surface_present()" request not accepts a timestamp (uint32_t<br> > > 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> > > 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> > ><br> ><br> > I'm a bit concerned about "attention", because toolkit authors usually have<br> > both a "present this window" and "mark this window as needing attention"<br> > API. Under X11, one maps to _NET_WM_ACTIVATE and the other maps to the<br> > _NET_WM_STATE_DEMANDS_ATTENTION flag. This request is the former, not the<br> > latter. If somebody IMs me, the taskbar button might blink, but it should<br> > never immediately raise and show the window.<br> ><br> > There's also on guarantee that this request will do focus-stealing or pay<br> > attention to the serial at all. For users that turn the behavior off, the<br> > window will simply pop up in front of them, and if app developers start<br> > using this as a non-obtrusive way of trying to gain attention, they will be<br> > disappointed.<br> ><br> > I don't want to bikeshed on the list though. I'll continue to brainstorm.<br> <br> </div></div>Right, ACTIVATE vs. DEMANDS_ATTENTION. I assume these are two<br> different things in X11, as the client can simply force its way.<br></blockquote><div><br></div><div>_NET_WM_ACTIVATE in X11 says "please show this window to the user". It's used for instance if I have an IM open with a person, and then I click their name in the buddy list again. It will switch to that window. It's used when clicking on a link and having the web browser open a new tab in its existing window. Or when opening files in a new tab in gedit. There is an event timestamp passed along, and the window-manager will switch to it if it's new enough. There is no guarantee the window will be immediately raised and available. The window manager *might* decide to downgrade the request to saying the window wants attention. This is what mutter does if the event timestamp is too old. [0] Imagine I click on a link, Firefox takes a while to start up, and then I keep chatting with my friend. Instead of having Firefox steal the focus, the request is downgraded to a blinking taskbar icon or a notification, so my keystrokes now go to my friend instead of being interrupted mid-type.<br> </div><div><br>_NET_WM_STATE_DEMANDS_ATTENTION in X11 is a hint to say "the window wants some attention. Feel free to show a notification, or blink the taskbar icon". It should never switch to the window.<br></div> <div><br></div><div>The proposed xdg_surface_present() extension is equivalent to _NET_WM_ACTIVATE. I am fine with calling it xdg_surface_activate().<br></div><div><br><a href="https://git.gnome.org/browse/mutter/tree/src/core/window.c#n3389">https://git.gnome.org/browse/mutter/tree/src/core/window.c#n3389</a><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> "Present this window" OTOH just means "map this window", and I do<br> not see an obvious reason why we would need that in the<br> Wayland protocol, as we can do the same with the first<br> wl_surface.commit that carries a wl_buffer. Sorry I haven't read<br> everything, maybe you already explained somewhere why we need a<br> "map/show" request? Do we have a way to hide, too?<br> <br> Note, that I imagine this is different to ACTIVATE, since in my<br> mind activating means getting some input focus and maybe even<br> raising to top. Quite likely I am just confused here on what you<br> mean, I'm playing based on what the names sound like.<br> <br> On Wayland, we cannot have "activate me now" request, we can only<br> have "I would like to be activated because...", and OTOH we have<br> the concept of demanding attention.<br> <br> What is the difference between demanding attention and wishing to<br> be activated? I didn't see a difference, and so conflated the<br> concepts.<br> <br> And which one was this xdg_surface_present supposed to be?<br> <br> Those two questions are my confusion here.<br> <br> If it is about ACTIVATE, call it something like "activate" then.<br> <div><div class="h5"><br> > > > <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<br> > > 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> > ><br> ><br> > We currently don't have a serial or timestamp in get_xdg_surface to do<br> > focus-prevention stealing on, and I figured that that calling present made<br> > sense, since then we don't have the "map on first commit semantics".<br> > Instead, now we have a request for "show the window to the user".<br> <br> > > 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> > ><br> ><br> > On X11, we have startup-notification, which is basically a hash map done as<br> > a sequence of add/remove broadcast ClientMessages. When you launch an app,<br> > you build a "startup notification" structure containing the thing you're<br> > launching and the event timestamp it was launched with, and send it as a<br> > ClientMessage. You then send the ID of that structure to the app, and when<br> > the app finally launches, the app broadcasts that it had launched, which<br> > removes the app from everybody's tracking.<br> ><br> > The important thing is actually the middle one: telling the app what ID it<br> > has. This is done with the DESKTOP_STARTUP_ID envvar.<br> ><br> > In places where startup-notification is too complicated, we have a somewhat<br> > silly ad-hoc convention that's not documented. You can set<br> > DESKTOP_STARTUP_ID to "_TIME123456", and that gives the app the event<br> > timestamp it was launched with, which it can use for _NET_WM_ACTIVATE and<br> > some other things.<br> ><br> > We could reuse this same scheme for Wayland. Put an event serial or a event<br> > timestamp in DESKTOP_STARTUP_ID so it knows what to pass to the initial<br> > present request.<br> <br> </div></div>Very good, except I do not believe a timestamp is a good one (easy<br> to fake, does not identify anything) nor a serial (does not<br> identify anything, is perhaps not a global concept), so you need to<br> ask the server to explicitly create a cookie for you to give to<br> the app being launched. And if the "present" request uses a serial,<br> the cookie needs to be converted to serial first, or maybe rather<br> another "present" request that directly uses the cookie.<br></blockquote><div><br></div><div>I had two (admittedly silly) issues with serials that made me choose timestamps instead of serials.<br><br></div><div> The first is that I didn't realize that they were on input events, because I looked at wl_pointer.motion. I suppose we'll be in trouble if we ever want mouse-gesture-based window opening, but for now, I think we're fine.<br> <br></div><div>The second is that "0" is a valid value for a serial, and sometimes you're in a place where you want to present a window and don't have any serial to pass back. Initial map where you don't have a launch serial (terminal launching is the obvious case) is a simple example. You can imagine other cases, though. A browser might do this:<br> <br></div><div> setTimeout(function() {<br></div><div> window.open("<a href="http://google.com/">http://google.com/</a>");<br></div><div> }, 5000);<br></div><div><br>Which says to the browser to open a new window after 5 seconds. We have no serial to pass here. Timestamps of 0 are decidedly less valid, so there's a good sentinel value there.<br> <br></div><div>Suggestions welcome. Both having two requests and a boolean "serial_valid" flag were both ugly to me. Maybe we should add maybe types to the protocol? :)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> But I'm glad my naive thinking got to roughly the same solution you<br> already have in X11. :-)<br> <br> Hmm, or do we not need to create any association between the<br> client that launches and and the client that is launched? If we<br> don't, then I suppose a serial would do for focus stealing<br> prevention, but I don't think it would work well for dismissing the<br> startup-notification.<br> <br> <br> Thanks,<br> pq<br> </blockquote></div><br><br clear="all"><br>-- <br> Jasper<br> </div></div>