autostart spec updates/extensions
vuntz at gnome.org
Sun Oct 8 22:29:39 EEST 2006
Am I really the first to reply? :-)
Le vendredi 22 septembre 2006, à 17:11, Dan Winship a écrit :
> There was a thread in February and March about extensions to the
> autostart spec, but nothing ever happened with it.
> There were three points being discussed then, and a few more I'd like
> to try to address as well.
> 1. XDG_CONFIG_DIRS or XDG_DATA_DIRS?
> First up was discussion of what the right place for autostart .desktop
> files was. The spec currently says autostart files are read from
> $XDG_CONFIG_DIRS/autostart. Some people apparently didn't like this,
> because all other .desktop files are in $XDG_DATA_DIRS. Waldo argued
> that that's irrelevant, because in this case, they're being used as a
> configuration mechanism, not as application data. This seems right to
> me. The problem was also raised that $XDG_DATA_DIRS/autostart would
> collide with the pre-fdo KDE autostart system, which causes problems
> because of apps that aren't marked OnlyShowIn=KDE, but should be if
> they're in what's considered to be a system-wide directory.
> So I'd argue with sticking with $XDG_CONFIG_DIRS/autostart. Is anyone
> really horribly opposed to this?
If I were a Debian developer (but I'm not :-)), I'd argue that we should
use $XDG_DATA_DIRS/autostart for the .desktop files shipped in packages
and $XDG_CONFIG_DIRS/autostart for .desktop files modified by
This would make sense, but this might be a bit far-stretched.
> 2. Immutability / Lockdown
> If the only case we really need to support is "lock down the whole
> file", then we could cheat and add a change to the autostart spec
> saying that if the .desktop file starts with an empty group named
> "[$i]", then the file is immutable. If we need to be able to put [$i]
> in other places for reasonable use cases, then it probably makes more
> sense to update the Desktop Entry Specification itself to add
> immutability, although this is a non-backward-compatible change to the
> syntax of .desktop files, so that might not fly.
I like the [$i] group idea.
FWIW, updating the desktop entry spec would be hard right now since we
don't talk about "inheritance" there.
> 3. X-KDE-autostart-condition
> KDE lets you specify that an app should only be started if a certain
> kconfig setting is set, eg:
> X-KDE-autostart-condition=kgpgrc:User Interface:AutoStart:false
> which means that the app should only run if the "AutoStart" setting in
> the "User Interface" group of the "kgpgrc" config file is true (and if
> it's not set, assume it's "false").
> This seems incredibly useful, except for the obvious
> KDE-specificness... There doesn't see to be a "One Config System To
> Rule Them All" on the horizon, but I think we can still standardize
> this. Given that KDE sessions are likely to be mostly filled with KDE
> apps and GNOME sessions are likely to be mostly filled with GNOME
> apps, etc, we ought to be able to punt on making this fully desktop
> agnostic. Something like:
> An application that only wants to be started if a certain
> configuration setting is set can use the Autostart-Condition key
> as a hint:
> Autostart-Condition: config-system:key
> "config-system" specifies one of the following configuration
> kconfig: KDE's KConfig system. The key name consists of the
> config file, group name, key name, and default value,
> separated by ":".
> gconf: GNOME's GConf system. The key name is a gconf path,
> which must point to a boolean-valued key. The schema
> determines the default value.
> exists: The key name is a filename relative to
> $XDG_CONFIG_HOME; if the file exists, the key is "true".
(except where the filename starts with / and then it's an absolute
> Autostart files MAY use config-system values not specified here,
> if they start with "x-" or "X-".
> Autostart-Condition: kconfig:kgpgrc:User Interface:Autostart:false
> Autostart-Condition: gconf:/desktop/gnome/remote_access_enabled
> Autostart-Condition: exists:MyApp/autostart
> Autostart-Condition: x-environment-variable:$FOO_ENABLED
environment-variable should probably standardized since it's easily
implementable and useful.
> There is no guarantee that the desktop environment launching the
> desktop file will be able to handle configuration keys of a given
> type (and in particular, desktop environments do not need to
> implement ANY of the config-system values described above). Thus,
> an application using this mechanism MUST still check the value of
> the configuration setting itself when it starts up, and exit if
> the key is not set.
> and add to Appendix C, "Deprecated Items":
> "X-KDE-autostart-condition: foo" means the same thing as
> "Autostart-Condition: kconfig:foo"
> (Another possibility would be that rather than specifying any
> desktop-specific config systems in the spec itself, just say that
> config-system names use reverse dns naming or something, and KDE would
> use "org.kde.kconfig" for its keys and GNOME would use
> "org.gnome.gconf" for its, and there would just be links from the
> autostart spec page on freedesktop.org to the pages that specified how
> those worked.)
> Anyway, the idea is that as long as the session manager isn't
> launching too many apps with unrecognized key types (which should be
> the normal case), then having the apps get started anyway and then just
> exiting when they check the key themselves won't be too awful.
> Furthermore, in the gconf case, it would always be possible for a
> non-GNOME SM to just use "gconftool-2" to fetch the value of the key.
> (Is there a corresponding command-line tool for kconfig?) This might
> be especially useful for the "minor" desktops, since their users are
> probably more likely to be running apps from other desktops.
++ for this addition.
It might be useful to specify more than one Autostart-Condition, though
(for example, a kconfig one and a gconf one). How could we deal with
this? Or is it really a case we can safely ignore?
> 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.
Agree. Priority is the simplest way to do this. I don't know if we'd
want to have a depend/provide key since this could make things a bit too
> 5. "autostop"
> Running stuff at logout (eg, cleaning up stuff?). Does KDE do anything
> with this currently? Do people really have good use cases for this
> (which couldn't just as easily be solved via XSMP-based logout
Use case #1: remove files from the user directory (useful for
administrator of internet cafes)
I'm sure we can think of some other use cases.
> 6. autorun/autoopen
> WTF??? The autorun/autoopen-on-volume-mount stuff is completely
> unrelated to autostart-at-login. Anyone opposed to booting this out
> into a separate spec?
I'm fine with this.
> 7. XSMP
> I noticed that KDE had someone hacking on XSMP-related stuff for
> Summer of Code. Is that stuff likely to be adopted?
> Given that XSMP and autostart are closely tied together, and given
> that XSMP is annoyingly underspecified, it seems to me like it might
> be nice to put some XSMP clarifications into the autostart spec
> (though maybe others would feel that this is just as out of place as
> the autorun stuff?)
Makes more sense to clarify the spec somewhere else, IMHO. We already
have something similar for the X clipboard:
I have another question: should a .desktop file in .config/autostart/
be able to depend on the content of another one in
/etc/xdg/autostart? For example:
Exec=gossip -a myaccount
And here's /etc/xdg/autostart/gossip.desktop
Obviously, we'll use .config/autostart/gossip.desktop. But shouldn't it
only be used in GNOME? The user .desktop file probably appeared because
the user edited this startup entry to change a bit the command line, but
he didn't want to remove the name or to allow it to run in another DE.
Thanks for working on this!
Les gens heureux ne sont pas pressés.
More information about the xdg