On 2018/7月/05 04:26, David Edmundson wrote: > This protocol is to address the following use case. > > A user clicks on a URL link in an IRC chat and a web browser opens. We want > an existing browser window to raise or if it's a newly spawned application > to claim focus on startup. > > Naturally we also don't want any arbitrary client to be able to raise > themselves arbitrarily. Since this steals focus, I have to agree. But what we do want, is a way for clients to gain attention. Probably via some kind of urgency flag on their toplevel. I think raising a window (or for virtual-desktops, changing the desktop) is the extreme case of this, so I think it would fit a general urgency/attention grabbing protocol. As I explain further down (I wrote this mail bottom up) I think we should be able to provide a way to allow the focus stealing, so we could have this in a protocl with a request family (or enum on one request?) for: Attention: e.g. console bell, or some password query for a background task Urgent: Something went wrong in e.g. gparted long-running process Raise/Show: e.g. browser got opened a new tab for another application
> > The protocol is a combination of xdg-foreign and some very simplified > aspects of X's startup-notification. > > In the example above, the chat client gets a token from the compositor and > passes it to the browser using: > - an environment variable for newly spawned apps > - platofrm-hints in the org.freedesktop.Application interface > - some hint in the relevant xdg-portal interface > - any custom mechanism There was a discussion about this very recently in the suggestion for session recovery, it's not quite this easy. And I think a quite common way to start applications (if we don't want to limit this to http[s]) is xdg-open, which I'm not sure if it provides for this use case. As Drew pointed out in his answer already, the out of band mechanism will not be the easiest thing to define. And when you read the previous discussion, you'll notice that the consense on which IPC to use isn't all that strong =.= > > The browser then requests a raise of a top-level using this token. > > (Exact common mechanisms should probably be defined, but maybe not in this > document) > > The exporter is virtually identical to xdg-foreign's exporter, but we can't > re-use directly it as it's important that clients know what the exported > handle could be used for. > > Extending xdg-foreign would be a viable solution, but the lifespan of > handles needs to be different.. > > Honouring the activation request is entirely up to the compositor which can > have whatever advanced focus rules it wants. > > Draft proposal below: I feel like this is a bit too specific and complicated for what's supposed to be achieved here. IMO we'd have a better solution (and more flexible to build on in the future) if this was split into two protocols, one for raising a window, and the other for passing serials. The former protocol would simply have a request to be raised, that takes a valid serial. This could also be used for applications with multiple windows if they want to have another of their windows focused (e.g. fancy editor when you try to open a file again). Then provide a secondary protocol that "hooks" into this one, by sharing serials. This would be a simpler protocol without a direct use, but could be used as base to share (implicit) permissions gated on user interaction between clients that intend to outsource some task. This protocol could largely look like xdg-foreign (maybe have the exporter one be destroyed implicit immediatly after the event) since serials have their own lifetime. > > ----------- > > <?xml version="1.0" encoding="UTF-8"?> > <protocol name="xdg_foreign_activator"> > > <copyright> > > </copyright> > > <description summary="Protocol for sharing focus between cross-process > xdg surfaces"> > This protocol allows a top level to give up focus and pass it to a > specific other client. > > An example use case would be a chat client opening a link in a > browser, that should raise an existing window > or start the newly opened window with focus. > > The application releasing focus (focus_exported) fetches a handle > from the compositor and then passes it to another client using a third > party mechanism. > > The receiving application can use this handle to request focus from > the compositor. > </description> > > <interface name="zxdg_focus_exporter_v1" version="1"> > <description summary="interface for exporting surfaces"> > A global interface used for exporting surfaces that can later be > imported > using xdg_importer. I think you meant to: s/xdg_importer/xdg_focus_activator/ > </description> > > <request name="destroy" type="destructor"> > <description summary="destroy the xdg_focus_exporter object"> > Notify the compositor that the xdg_exporter object will no longer be > used. > </description> > </request> > > <request name="export_surface"> > <description summary="export a toplevel surface"> > It is an error to export a focus that is not mapped. > </description> > <arg name="id" type="new_id" interface="zxdg_focus_exported_v1" > summary="the new xdg_exported object"/> > <arg name="surface" type="object" interface="wl_surface" > summary="the surface to export"/> > </request> > </interface> > > <interface name="zxdg_focus_exported_v1" version="1"> > <description summary="an exported activation handle"> > </description> > > <request name="destroy" type="destructor"> > <description summary="unexport the exported surface"> > Inform the compositor that this focus_exported object is no > longer used. > The handle remains valid and can still be used by the compositor. > This is to allow windows to close themselves > after activating another application. > </description> > </request> > > <event name="handle"> > <description summary="the exported activation handle"> > The handle event contains the unique handle of this exported surface > reference. It may be shared with any client, which then can use it > to > import the surface by calling zxdg_activator_v1.activate_toplevel. > A handle > may be used only once. > </description> > <arg name="handle" type="string" summary="the exported activation > handle"/> > </event> > </interface> > > <interface name="zxdg_focus_activator_v1" version="1"> > <description summary="interface for importing surfaces"> > A global interface used for importing surfaces exported by > xdg_focus_exporter. > With this interface, a client can create a reference to a surface of > another client. > </description> > > <request name="destroy" type="destructor"> > <description summary="destroy the xdg_activator object"> > Notify the compositor that the xdg_activator object will no longer > be > used. > </description> > </request> > > <request name="activate_toplevel"> > <description summary="activate a toplevel surface"> > Request to the compositor that this surface should claim focus > from the exported handle. > > This request can be sent at any time to raise an alread mapped > window or before the window is > mapped to request focus when the window is first configured. > > At this point the handle is invalidated and cannot be used again. > > The compositor is free to ignore this request. > </description> > <arg name="toplevel" type="xdg_toplevel"> > <arg name="handle" type="string" > summary="the exported activation handle"/> > </request> > </interface> > > </protocol> > _______________________________________________ > wayland-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
signature.asc
Description: PGP signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
