autostart spec updates/extensions

[Bastian, Waldo]

>On Fri, 2006-09-22 at 17:11 -0400, Dan Winship wrote:
>> 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.
>>
>> Basically the system is:
>>
>> 	- if a key has [$i] at the end of the name, it's immutable
>> 	  (can't be changed or deleted)
>> 	- if a group name has [$i] after it (eg, [Desktop Entry][$i]),
>> 	  the whole group is immutable (no keys can be changed, added,
>> 	  or deleted)
>> 	- if the file has [$i] as its first group name, the whole file
>> 	  is immutable
>>
>from using the autostart mechanism for a few months now, and having got
>some feedback from users, it seems to me we only want to lock the whole
>file, thus having a Locked=true|false property would be enough. That
is,
>why would you want to allow the user to change the Exec line but not
>Hidden, for instance? Admins, at least from my experience, usually just
>want to force the app to always be started, or just allow the user to
>disable it, and for that we just need that Locked=true|false

I agree... so I suggest to use the notation of using [$i] as a first
group to mark the file immutable, and ignore the other immutable
notations that KDE supports. 

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

The system-wide version, when locked, must take precedence, otherwise
there is no effective locking. The user's version should be ignored to
maintain the notion of a unified namespace. (The concept of $XDG_*_DIRS
is based on the notion that the base filename identifies the resource
and that the actual path is irrelevant)

Cheers,
Waldo