>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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
