autostart spec updates/extensions

[Dan Winship]

Aaron J. Seigo wrote:
> we support $i as we do consistently across all configuration files. this 
> avoids special rules in specific places and avoids us having to prognosticate 
> what the admins/users of the world wish to do. they can simply do what they 
> want, our code remains simple and consistent, nobody complains.

Using [$i] would be consistent with KDE, but inconsistent (and in fact,
syntactically incompatible) with the FDO .desktop file spec.

At any rate, while fine-grained lockdown is useful in some of the other
places where KDE uses ini-style files, it's not clear that you can
usefully lock down just a subset of an autostart file. A user can
disable a system autostart item by changing Type, Version, Hidden,
OnlyShowIn, NotShowIn, TryExec, Exec, or Path (and in some cases
Terminal), so at a minimum you have to lock down all of those, and even
then there's the possibility that a newly-added key or a
desktop-specific key (like X-KDE-Autostart-Condition) would give the
user another opportunity to disable it. So the only reliable way to lock
down an autostart file is to lock down at least the entire [Desktop
Entry] group, and at that point, the argument for using the
"backward-compatible" [$i] notation rather than a simple "Locked=true"
becomes a lot weaker.

>> Also, for the lockdown, we need to sort out what to do when the user
>> puts a file with the same name of a locked system-wide .desktop file, in
>> his ~/.config/autostart. Should the user's file be used in place of the
>> system-wide? Or, should the system-wide, when locked, have precedence
>> over the user's changes?
> 
> system wide files always have precedence.

Assuming you mean "for lockdown purposes", then sure. Lockdown is
completely pointless otherwise. But for everything else, the autostart
spec says that the user's version has precedence over the system version
(which is necessary if you want users to be able to disable
non-locked-down system autostart files).

-- Dan