autostart spec updates/extensions

[Lubos Lunak]

On Friday 22 September 2006 23:11, Dan Winship wrote:
> 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?
...
> According to the ksmserver
> README, KDE looks in "$KDEHOME/share/autostart", and AFAICT from the
> source code, this is correct; I don't think it looks at $XDG_DATA_DIRS
> at all, and I don't think it does fdo-autostart out of any user
> directories.

 It would be trivial to add. Or wouldn't, depending on how hard the spec tries 
to be incompatible with KDE (which would be especially absurd given that it's 
based on it).

> 2. Immutability / Lockdown
>
> We want some way for the administrator to lock down certain aspects of
> autostart. (Eg, "you can't remove this app from the startup items
> list".)
>
> KDE already has a widely-used system for marking part or all of a
> .desktop file immutable, and that gets used by their autostart system
> already, so there's a strong argument for just adopting that.
>
...
> So basically you have to mark either the whole [Desktop
> Entry] group immutable, or the whole file. (I think? Anyone got an
> exploit against that?)

 Yes, just using the autostart spec: "If the same filename is located under 
multiple Autostart Directories only the file under the most important 
directory should be used." I don't know if this is a mistake or was done on 
purpose, but it's a) incompatible with KDE, b) it breaks lockdown. And the 
same is true for the menu spec.

 KDE does not use the most important file, it processes entries from less to 
more important ones and new ones replace old ones. Waldo would be the right 
person for this, but if I'm not mistaken it works like this:

/global/file.desktop:
[Group]
Entry1=foo
Entry2[$i]=bar

~/.local/file.desktop:
[Group]
Entry2=whatever
Entry3=something

The "resulting file" is:
[Group]
Entry1=foo
Entry2[$i]=bar
Entry3=something

[$i] stops processing more important files for the entry, but if you take only 
the most important one, you have no chance to enforce that. This system also 
allows having things like global defaults and local changes.

> 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").
...
>     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
>
>     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.

 In other words, what's above would be useless anyway. Besides, I thought it 
was already said that this autostart condition can be simply replaced by 
using Hidden=true in the local file? I don't think autostart conditions are 
used for anything else then "autostart? yes/no" and whoever writes the config 
value can as well just write the Hidden=true.

> 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.

 No, thank you very much. Some people who have spent quite some time on making 
the startup as fast as possible wouldn't be very happy about this. Let's just 
keep it simple with Hidden=true, ok?

> 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.

 Let me answer in the other mail.

> 5. "autostop"[2]
>
> Running stuff at logout (eg, cleaning up stuff?). Does KDE do anything
> with this currently?

 We have $KDEDIR/shutdown/*.sh .

> Do people really have good use cases for this (which couldn't just as easily
> be solved via XSMP-based logout notification)?

> 7. XSMP
>
> I noticed that KDE had someone hacking on XSMP-related stuff for
> Summer of Code. Is that stuff likely to be adopted?

 Depends. Hopefully. It's not really down to the level of XSMP though.

> Given that XSMP and autostart are closely tied together,

 XSMP and autostart are not closely tied together. Well, not more than hot 
chocolate and icecream can be closely tied together. XSMP and autostart 
basically conflict (and I've cursed autostart many times for being just 
hacked in without thinking about XSMP at all while fixing bugs).

> 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?)

 Separate. However, it first might be a good idea to actually say how they are 
supposed to relate together. Autostart is not that much more than an internal 
mechanism to start desktop components and a more ugly way to have session 
saving ("do you want to start XYZ next time?").

> There are probably others. (Oh, I just discovered that ksmserver
> doesn't use SmEnvironment when restarting saved apps, and in fact, the
> XSMP spec never actually says that you're supposed to... sigh.)

 There's a bugreport about this, but I don't feel very urged to do something 
about it. Finding out which env.vars to save and which ones not doesn't sound 
like a nice thing.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz