[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Application launch detection



Hi,

We were recently discussing how to provide a progress indicator while
an app is launching in future versions of GNOME. 

This list has had posts on it in the past, describing how KDE 2.0 works:
  http://mail.gnome.org/archives/wm-spec-list/2000-September/msg00000.html

There's a little utility called Xalf that addresses the issue:
  http://www.lysator.liu.se/~astrand/projects/xalf/

The Xalf page links to this post from Rik on a KDE list:
  http://lists.kde.org/?l=kde-devel&m=95246257913097&w=2

As I understand from Rik's mail, KDE 2.0 uses the PID property from
the WM spec to detect that an app has launched. A separate extension 
adds the boolean field MapNotify to the .desktop files, so that
launchers such as the panel know whether to expect to see a window
with the PID property on it.

The author of Xalf points out that the PID method breaks down in
several cases; for example, when an app is run from a wrapper script. 
So Xalf improves on this by having the launching app set an env
variable which the launch app advertises on mapped windows.

Several proposals:

 1) We should specify a property on app windows that is set to the
    value of the environment variable DESKTOP_LAUNCH_ID. If
    DESKTOP_LAUNCH_ID is not set, then the property is not set
    either. The value of DESKTOP_LAUNCH_ID can be any string, it's
    totally interpreted by the launching application, but should
    contain some kind of namespacing and some kind of globally
    random/unique value. The property could be called _NET_LAUNCH_ID I
    suppose.

    Apps should put the LAUNCH_ID on all their windows throughout the 
    lifetime of the application.

    This is for version 2.0 of the WM spec, but I'd like to get some 
    agreement now since GNOME will likely implement before then.

 2) Launching apps should stop displaying progress if a window 
    is mapped with _either_ the PID/machine or the DESKTOP_LAUNCH_ID of 
    the app being launched. If the launch ID doesn't match but the PID 
    does, however, the PID can be ignored (since theoretically 
    the launch ID is more reliably unique). Since the PID/machine
    pair is still supported, the LAUNCH_ID is backward compatible 
    with e.g. KDE 2.0 apps.

 3) We standardize on MapNotify=true as an indicator in .desktop
    files that the launched app is expected to set at least the PID
    and machine properties, and is expected to open at least one
    window.

    Which reminds me that we need to get the .desktop spec written 
    down...

What do people think?

Havoc





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]