On Fri, 1 Aug 2014 17:08:14 +0200 Manuel Bachmann <manuel.bachm...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel