autostart spec updates/extensions

[Vincent Untz]

Hi,

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[1], 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
administrators.

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:
> 
>     Autostart-Condition
> 
>     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
>     systems:
> 
> 	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
filename)

>     Autostart files MAY use config-system values not specified here,
>     if they start with "x-" or "X-".
> 
>     Eg:
>       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
complex.

> 5. "autostop"[2]
> 
> 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
> notification)?

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:
	http://freedesktop.org/wiki/Standards_2fclipboards_2dspec

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:
Here's .config/autostart/gossip.desktop
[Desktop Entry]
Exec=gossip -a myaccount

And here's /etc/xdg/autostart/gossip.desktop
[Desktop Entry]
Name=Gossip
Exec=gossip
OnlyShowIn=GNOME;

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!

Vincent

-- 
Les gens heureux ne sont pas pressés.