autostart spec, round 2!

[Dan Winship]

OK, trying to summarize what's gone on so far...

Dan Winship wrote:
> 1. XDG_CONFIG_DIRS or XDG_DATA_DIRS?

No one has really objected to sticking with $XDG_CONFIG_DIRS/autostart,
which is what the spec currently says, and which GNOME already does.

> 2. Immutability / Lockdown

This also ties into the issue of top-down vs bottom-up merging /
whether or not user-level .desktop files can override single keys from
system-level ones (where the spec currently requires a behavior that's
incompatible with standard KDE behavior).

For lockdown, I don't love "[$i]", but I can certainly live with it, and
I haven't heard anyone else say they can't. I don't think per-key
lockdown makes sense for desktop files though, because it's frequently
the case that individual keys effectively change the meaning of the
entire desktop file. Eg, "Hidden[$i]=false" doesn't prevent you from
disabling the app, because you can still add "TryExec=/doesn't/exist".
There's no need for the spec to forbid KDE from using per-key lockdown
if it wants to though.

Per-key override seems more useful. Eg, it lets you write a .desktop
file with just "Hidden=false" to enable a normally-disabled system-wide
service, while automatically picking up changes to command-line args,
translations, etc from the main .desktop file. OTOH, Waldo gives an
example where overriding one key in the user-level desktop file would
cause problems if other keys were changed in the system-level one...

Here's the old text:

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

Here's what I propose: (Ignore the fact that it describes something
different from what KDE actually does; the important part is that they
get the same end result, which they do.)

    If the same desktop filename is located under multiple Autostart
    Directories, the startup system must merge the files together as
    follows:

        - The .desktop file in the least-important directory is used
          as a base; if it does not contain all of the keys REQUIRED by
          the Desktop Entry Specification, then the startup system's
          behavior is not defined.

        - Each following desktop file with the same name is then
          processed as follows, in order of increasing importance.

            - If the file is missing any of the keys that are REQUIRED
              by the Desktop Entry Specification, then it is interpreted
              as a "patch" relative to the previous desktop file, and
              the values of its keys override the previous values of
              those keys. Eg, a file containing only

                  [Desktop Entry]
                  Hidden=true

              would keep all of the keys from the previously-specified
              desktop file except for "Hidden", which would now be set
              to "true".

            - If it is not missing any REQUIRED keys, then the startup
              system MAY interpret it either as a patch or as a complete
              replacement for the earlier .desktop file. (There is no
              way for a portable application to know what behavior the
              startup system will use in this case.)

        - If a file contains the string "[$i]" on a line by itself
          before the "[Desktop Entry]" group, then its contents are
          considered immutable, and the startup system will not merge
          in the contents of any further directories.

Followed by some examples.

Per-key [$i] is unspecified; KDE can implement it and that's fine.

Merging is allowed in clearly-useful cases (like changing Hidden), and
the startup system has the option of blocking it in other cases (which
GNOME will probably do, and KDE probably won't unless Waldo changes
Lubos's mind. Although in that case we should just get rid of the
unspecified behavior part.)

> 3. X-KDE-autostart-condition

Lubos points out that apps can just toggle the Hidden flag on a per-user
basis. This has pros and cons:

    Pro:
      - No additional spec text needed
      - 100% compatible all-around rather than having egregiously
        KDE-specific and GNOME-specific bits

    Con:
      - Difficult for app authors to use until we get new APIs out
        there to read/write the files for them
      - Moves part of the application's configuration state out of the
        standard place (kconfig/gconf)
      - May not work well if people reject the key merging proposal
        above

I like it though. Anyone else got comments?

> 4. Other KDE extensions?
> 
> Are there any other extensions from KDE autostart that we should
> absorb? The only other one I'm aware of is X-KDE-autostart-phase.
> 
> Having some sort of priority/phase system seems like a good idea.

This hasn't gotten very far, and what I proposed doesn't really map very
closely to KDE startup. Having thought about it some more, I think that
startup ordering is the sort of thing that makes more sense *not* being
standardized. It's only the desktop-specific apps that need to care
about exactly when they get started up, and they can use desktop-
specific mechanisms to specify that. Ordinary apps don't need to care
when they get started, so there's no need for any cross-desktop spec here.

> 5. "autostop"[2]

Lubos pointed out what KDE does. I haven't looked into this much yet.
"Still under investigation".

> 6. autorun/autoopen

No objections to splitting this out.

> 7. XSMP

At a minimum, we need some way for the session manager to recognize that
an XSMP client corresponds to something it autostarted, so it can avoid
duplicates. Maybe we can use startup notification here? Have the app
pass its DESKTOP_STARTUP_ID back to the session manager as an XSMP
property, and the SM can match that against the desktop files it started
to find a match. (Whatever we do here, it's not going to work 100% of
the time, since the SM can't force the user to only autostart apps that
know about this spec.)

-- Dan