Autostart Spec 2007

[Dan Winship]

OK, I finally got back to this after a few months of hacking on the
actual code to get a stronger idea of what I wanted from the spec.

Quick summary of the open issues:

> File-level vs. Key-level Override / Immutability / Lockdown

No consensus here. GNOME implements this the way the spec says to
(except buggier). KDE doesn't implement overriding of autostart
items at all currently, but if they did, they'd want to do it the same
way they do it everywhere else, which would conflict with the spec.
For lockdown, no one has yet given a use case where autostart lockdown
would be enforceable without also locking down so much other stuff
that autostart lockdown would be unnecessary.

> Autostart-Condition

Some people didn't like my original proposal for a standardized
Autostart-Condition, which suggested that desktop environments might
at least optionally want to read keys from foreign config systems.
Lubos counterproposed that apps could just write .desktop files to
~/.config/autostart toggling their Hidden keys.

> XSMP clarifications

We should at least give some hints on how to make autostart and XSMP
work well together.


So now, here are my latest thoughts...



Autostart-Condition
-------------------

The goal here is that all applications (and in particular, "third
party" apps, since they're the ones that need cross-desktop standards
the most) should have access to the behavior that KDE apps currently
get with X-KDE-autostart-condition; there should be an easy way for
them to make themselves autostart or not autostart, and they should be
able to tell what state they're currently in (so that they can set the
"Autostart?" checkbox in their prefs dialog to the right state, etc).

The idea of just writing out files to ~/.config/autostart toggling the
Hidden key doesn't actually work very well, because of that last
requirement: it's difficult/impossible for an app to figure out
whether or not it's currently enabled for autostart. In the best case,
the app would need to check each path in $XDG_CONFIG_DIRS/autostart,
merge the .desktop files together appropriately according to the spec,
and see what the state of the Hidden key is at the end. But in
reality, even that won't work, because (1) both GNOME and KDE also
read autostart files from other directories besides
$XDG_CONFIG_DIRS/autostart, which the app won't know about, and (2)
future changes to the spec (eg, adding lockdown) might change the
rules for interpreting the .desktop files in such a way that the
session manager and the app would come up with different values for
the merged Hidden key.

The big problem with my original Autostart-Condition proposal was that
in some cases, a session manager would encounter a "foreign" config
key. Eg, beagled might have a gconf key indicating whether or not to
start it, which ksmserver would not want to have to interpret. The
easy fix for this is to say that desktop-agnostic apps MUST use
desktop-agnostic Autostart-Conditions, and any app that uses a
desktop-specific Autostart-Condition (kconfig, gconf, etc) will
*automatically* be considered to be desktop-specific (as though it
also had an OnlyShowIn).

Looking at how autostart has been used in the last few versions of
SUSE/openSUSE, it seems like this should work fine; In 10.2 the only
app autostarted under both GNOME and KDE is beagled. In 10.1 there was
the gtk-based updater trayicon that was also used under KDE, and in
10.0 and earlier, there was a Qt-based updater trayicon that was also
used under GNOME. In all of these cases, the authors of the app knew
that the app was going to be used cross-desktop, so they would have
known they should use a desktop-agnostic Autostart-Condition (had that
been available).

So:

    The Autostart-Condition Key

    The Autostart-Condition key gives a condition which should be
    tested before autostarting the application; if the condition is
    not met, then the application MUST NOT be autostarted. The
    condition can be in one of the following forms:

        if-exists FILE

    	    The application should only be autostarted if FILE exists
    	    (relative to $XDG_CONFIG_HOME).

        unless-exists FILE

    	    The application should only be autostarted if FILE
    	    *doesn't* exist (relative to $XDG_CONFIG_HOME).

	DESKTOP-ENVIRONMENT-NAME [DESKTOP-SPECIFIC-TEST]

	    The application should only be autostarted under the named
	    desktop environment (as with OnlyShowIn). If
	    DESKTOP-SPECIFIC-TEST is also given, the desktop
	    environment will evaluate it in some manner specific to
	    that desktop to determine whether or not the application
	    should be autostarted.


which would end up being used like:

    Name=kgpg
    # start only under KDE, and only if the given kconfig key is set
    Autostart-Condition=KDE kgpgrc:User Interface:AutoStart:false

    Name=vino
    # start only under GNOME, and only if the given gconf key is set
    Autostart-Condition=GNOME /desktop/gnome/remote_access/enabled

    Name=beagled
    # start under any desktop environment, unless
    # ~/.config/beagle/disable-autostart exists
    Autostart-Condition=unless-exists beagle/disable-autostart



Override / Immutability / Lockdown
----------------------------------

The spec currently says:

    If the same filename is located under multiple Autostart
    Directories only the file under the most important directory
    should be used.

Rather than continuing the debate about per-key vs whole-file
override, I'm going to suggest this replacement:

    If the same filename is located under multiple Autostart
    Directories, the result is implementation defined.

Crazy? Well, first note that it's what we have de facto right now, and
then consider that there are really only three cases where having a
well-defined behavior would matter:

    1. If an application wants to be able to change its own autostart
       .desktop file

    2. If an application wants to be able to change *someone else's*
       autostart .desktop file (ie, a cross-desktop session editor
       tool)

    3. If a user locally overrides a system autostart file in some way
       from within one desktop environment, and then switches to a
       different desktop environment (which interprets the changes
       differently).

#1 should not ever be necessary if we have a standardized
Autostart-Condition key that the application can use to toggle whether
or not it is autostarted. (If it needs to change some aspect of its
behavior other than whether or not it is autostarted, it can just set
some preference, and then check that at startup.) #2 seems
implausible. #3 is also unlikely (most users will never make weird
autostart changes, and never switch desktop environments, let alone
doing both), but if people think it's likely to become a problem, we
could just recommend that desktops shouldn't put users in that
situation:

    If the same filename is located under multiple Autostart
    Directories, the result is implementation defined. Desktop
    environments MAY allow users to override installed autostart
    files, but MUST store that information in a way that will not
    cause problems for other desktop environments. (Eg, it could store
    the changes in files with an extension other than ".desktop", or
    it could put them in a directory other than
    $XDG_CONFIG_HOME/autostart.)




XSMP clarifications
-------------------

The general problem is "if an app is autostarted, and then you save
the session, you don't want to start two copies of it when you resume
the session". The possibilities seem to be:

    1. Prevent duplicates from being able to happen at all. Eg, make
       sure that autostarted apps never XSMP-save themselves. Since
       the user can choose to add arbitrary programs to
       $XDG_CONFIG_HOME/autostart, the only way to do this reliably
       would be to unset SESSION_MANAGER when autostarting apps, but
       that would mean that their children couldn't use session
       management either. So this isn't a very good solution.

    2. Resolve the duplicates at startup time. This is what
       gnome-session currently does, by comparing the argv[0] of
       autostart Exec keys and XSMP RestartCommands. There are obvious
       problems with this in theory, although it seems to actually
       work pretty well in practice, at least for GNOME. (Maybe it
       wouldn't work as well in KDE with all the "Exec=kfmclient ..."
       etc. sort of stuff.)

       We could also add something to the spec to make this easier,
       such as:

       2a. Lubos's idea of a .desktop key indicating that the app
           supports XSMP, so that when the SM is resuming a saved
           session, it can assume that the app will be started via
           XSMP and skip it for autostart.

    3. Resolve the duplicates at session-save time (and record that
       information so that you can do the right thing when resuming).
       Eg, if the XSMP client sets SmProcessID, you might be able to
       match that to the PID of an app you'd autostarted. Or, if you
       use startup notification when launching autostart apps, then
       you can later look for a window with the appropriate
       _NET_STARTUP_ID property and see if it also has an SM_CLIENT_ID
       property set, etc.

       As with #2, we could add something to the spec to make this
       easier, such as:

       3a. If the app supports startup notification, it could also set
           a new XSMP property to the value of its DESKTOP_STARTUP_ID,
           so the SM can identify it more easily.

       3b. We could add a new .desktop file key "AutostartNotify". If
           the app sets it to "true", the SM would set the
           DESKTOP_AUTOSTART_ID environment variable to a valid SM
           client ID when autostarting the app, and the app would then
           pass that ID to SmcOpenConnection() (and unset the
           environment variable so its children don't try to use it
           too). This lets the SM immediately match the XSMP client to
           the corresponding autostart app.

(Even if we add something to the spec, we probably still want to
recommend that SMs do something like #2 or #3 as well, because it will
take a while before all apps support the new thing.)

I like #3b, because AutostartNotify also solves another problem: if an
application wants to behave differently when it's autostarted than it
does when it's started via the menus, it currently needs to specify
different Exec lines in its standard .desktop file and its autostart
.desktop file. Having AutostartNotify would solve that problem (it
could just test whether or not $DESKTOP_AUTOSTART_ID was set instead),
moving us a little closer to the only-one-desktop-file-per-app ideal.

The other nice feature #3a and #3b have over #2a is that they let you
figure out *exactly* which autostart item a given XSMP client
corresponds to, so at startup time the SM can combine the RestartCommand
from the XSMP state with the other information from the autostart
.desktop file (eg, X-KDE-autostart-phase, X-KDE-autostart-after, etc).
With #2a, you can't do that.

OTOH, #2a only requires changes to .desktop files, not any new code,
and so it could even be trivially applied to crufty old Motif apps and
crap like that. Then again, the crufty old Motif apps will almost
certainly work with plain #2 anyway.

So my recommendation here is to add
AutostartNotify/DESKTOP_AUTOSTART_ID to the spec, mention #3 as a
possibility (and say that clients SHOULD set the SmProcessID property,
which is optional in the XSMP spec), and recommend #2 as a fallback.

-- Dan