On Mon, 15 Feb 2016 16:59:02 +0800 Jonas Ådahl <jad...@gmail.com> wrote:
> On Thu, Feb 11, 2016 at 01:52:36PM +0100, Carlos Garnacho wrote: > > The xdg_launcher interface is added for the launcher, it's used > > to notify of the startup ID to be transmitted to the launchee, > > plus notifications about the startup success/failure. > > > > On the launchee side, we now have xdg_shell.set_startup_id, > > which will notify the compositor of startup finalization. > > > > This has been made to be compatible with the XDG Startup > > Notification spec available for X11, the startup ID is > > transmitted from the launcher to the launchee in the same > > ways, so we can launch x11 from wayland applications and > > viceversa. The notable difference is that wayland launchers > > receive startup IDs that are guaranteed to be unique, whereas > > in X11 this is a best effort of the launcher client. > > > > Some notes have also been added about focus stealing prevention, > > although that's mostly up for compositors to implement. > > > > Signed-off-by: Carlos Garnacho <carl...@gnome.org> > > --- > > > > I've got no full implementations yet, so this is mostly an RFC at the > > moment. I mainly wonder, should we add a "serial" argument to the > > create_launcher request? that'd at least ensure the launcher application > > has some sort of focus, although nothing prevents an application from > > being a fork bomb otherwise. > > Hey, > > I assume the compositor would have to limit to one startup per event > or something like that if you add the serial? Doesn't seem to prevent > fork bombs anyhow, the client can still fork as much as it wants. What > it does limit is, say, opening an application as a response to not-user > interaction. I don't have any reasonable use cases except remote > controlled clients not being able to do this properly. > > Overall, I'd like to see this being added as a separate extension. The > reason is that I don't think this belongs in a "core" xdg shell > interface, which we should try to keep as minimal as reasonable. It > could for example be a "xdg_startup_notification" global (well, > zxdg_startup_notification_v1 until later), which contains the requests > you added to xdg_shell. > > > > > unstable/xdg-shell/xdg-shell-unstable-v5.xml | 71 > > +++++++++++++++++++++++++++- > > 1 file changed, 70 insertions(+), 1 deletion(-) > > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml > > b/unstable/xdg-shell/xdg-shell-unstable-v5.xml > > index 542491f..1c4ef54 100644 > > --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml > > @@ -27,7 +27,7 @@ > > DEALINGS IN THE SOFTWARE. > > </copyright> > > > > - <interface name="xdg_shell" version="1"> > > + <interface name="xdg_shell" version="2"> > > <description summary="create desktop-style surfaces"> > > xdg_shell allows clients to turn a wl_surface into a "real window" > > which can be dragged, resized, stacked, and moved around by the > > @@ -135,6 +135,35 @@ > > </description> > > <arg name="serial" type="uint" summary="serial of the ping event"/> > > </request> > > + > > + <!-- version 2 additions --> > > + <request name="create_launcher" since="2"> > > + <description summary="create a new launcher"> > > + Creates a new launcher context. > > + > > + The surface argument is the toplevel where the application > > + was launched from, compositors may want to place the launched > > + application relative to the launcher surface. > > + > > + Compositors that desire to implement focus stealing prevention > > + can mark the time this request is received as the "startup" time. > > Not sure paragraph this belongs here. Compositors may do more things, > and doesn't seem to be useful to list those things here. Maybe it would > be good to add some high level blurb about how focus stealing prevention > could be done in some generic place (for example <description> in > <protocol> if it's its own extension protocol). > > > + </description> > > + <arg name="id" type="new_id" interface="xdg_launcher"/> > > + <arg name="surface" type="object" interface="xdg_surface"/> > > + </request> > > + > > + <request name="set_startup_id" since="2"> > > + <description summary="set the application startup_id"> > > + Notifies the compositor of the startup ID of this launched > > application. > > + Applications will typically receive this through the > > DESKTOP_STARTUP_ID > > + environment variable as set by its launcher, and should unset the > > + environment variable right after this request, in order to avoid > > + propagating it to child processes. > > + > > + Compositors will ignore unknown startup IDs. > > + </description> > > + <arg name="startup_id" type="string"/> > > + </request> > > How does this work when the application was already running? For example > if the launcher opened gedit with a new file, but gedit was already, how > is it communicated that the launched application was actually already > launched? Does gedit need to communicate internally and call this > request again? Or does the "hey gedit, wake-up!" process need to make an > additional Wayland connection and call this? Hi, should the startup-id be used per-window instead? Wouldn't a user usually be expecting a new (or an old) window to pop up? Or should the launched application be potentially able to raise any number of independent windows from a single launch? > > </interface> > > > > <interface name="xdg_surface" version="1"> > > @@ -622,4 +651,44 @@ > > </event> > > > > </interface> > > + > > + <interface name="xdg_launcher" version="2"> > > + <description summary="context for launching applications"> > > + xdg_launcher allows clients to get the necessary context to launch > > + applications, so the compositor can provide feedback about the > > + application being launched. > > + </description> > > + > > + <request name="destroy" type="destructor"> > > + <description summary="destroy xdg_launcher"> > > + Destroys this xdg_launcher object. > > + </description> > > + </request> > > + > > + <event name="startup_id" since="2"> > > + <description summary="startup ID for the launched application"> > > + Notifies of an unique startup_id (eg. UUIDs) to be used for the > > + application about to be launched. > > + > > + In order to guarantee interoperation with the XDG Startup > > Notification > > + spec, this startup_id is recommended to be transmitted to the > > launched > > + application through the DESKTOP_STARTUP_ID environment variable. > > It is unclear when this event will be received. > > I assume the flow of the client is: > > 1. client decides it wants to start application X > 2. <- xdg_shell.create_launcher > 3. -> xdg_launcher.startup_id("XYZ123") > 4. fork(); setenv("DESKTOP_STARTUP_ID", "XYZ123"); exec("/path/to/Application > X"); > > ... either some timeout(?) or the new appication called > xdg_shell.set_startup_id("XYZ123") > > 5. <- xdg_launcher.done / xdg_launcher.cancelled > > This flow should be spelled out semewhere (or the correct flow if I got > it wrong). By adding it as a separate extension, a good place would be > the <description> inside the <protocol>. > > > Jonas > > > + </description> > > + <arg name="startup_id" type="string"/> It's cool that this is a string chosen by the compositor. The compositor can store not only an id but any parameters it might want to relay in a cryptographically signed string (thanks to RAOF for the idea). Are there any limitations on what characters are allowed in the string? > > + </event> > > + > > + <event name="cancelled" since="2"> > > + <description summary="the launcher has expired"> > > + Notifies that the compositor is no longer watching this launched > > + application. > > + </description> > > + </event> > > + > > + <event name="done" since="2"> > > + <description summary="the launch operation was performed"> > > + Notifies that the launched application successfully called > > + xdg_shell.set_startup_id after startup. > > + </description> > > + </event> > > + </interface> > > </protocol> > > -- How will the compositor show an indication of some app being launched? Can it e.g. show it's icon with a placeholder somehow? Hope you don't mind these fly-by comments. Thanks, pq
pgp9F31brTgj2.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel