The KDE File System Standard
Since the very beginning KDE has made use of file-hierarchy to
store resources for its applications. Resources range from icons,
wallpapers, fonts to sounds, menu-descriptions and configuration
files.
In KDE 1 there were two locations were resources could be
located: the resources provided by the system where located under
$KDEDIR and user
specific resources where located under $HOME/.kde.
In KDE 2 resource management has been largely abstracted by
the introduction of the KStandardDirs class and
has become much more flexible. The user or administrator can now
specify a variable number of locations where resources can be found. A
list of locations can either be specified via $KDEDIRS
(notice the extra S), via
/etc/kderc and even via the
kdeglobals config file. The location where user
specific resources can be found can be set with
$KDEHOME (The default is $HOME/.kde). Changes made
by the user are always written back to $KDEHOME.
Both KDE 1 and KDE 2 feature so called “cascading
configuration files”: There can be multiple configuration files
with the same name in the various locations for (config) resources,
when that is the case, the information of all these configuration
files is combined on a key by key basis. If the same key (within a
certain group) is defined in more than one place, the value of the key
for the config file that was read last will override any previously
read values. Configuration files under $KDEHOME are
always read last. This ensures that after a configuration entry is
written, the same value wil be read back.
In KDE 3 two important changes have been made:
Default values are no longer written.
When a configuration file in a location other than
$KDEHOME defines a value for a key and the application
subsequently writes out a new configuration file to
$KDEHOME, that configuration file will only contain an
entry for the key if its value differs from the value read from the
other file.
This counters the problem that changing default configuration
files under $KDEDIR would not take effect for users,
since these users would most likely have their own copy of these
settings under $KDEHOME. KDE 3 will make sure not to
copy these settings so changes made under $KDEDIR will
affect all users that haven't explicitly changed the affected settings
to something else.
Configuration entries can be marked
“immutable”.
Starting with KDE 3, configuration entries can be marked
“immutable”. When a configuration entry is immutable it
means that configurations files that are read later will not be able
to override its value. Immutable entries can not be changed via
KConfig and if the entry is present under $“KDEHOME” it
will be ignored.
Entries can be marked immutable on 4 different levels:
- On an entry by entry basis by appending [$i]
after the key.
Example:
[MyGroup]
someKey[$i]=42
- On a group by group basis by appending [$i]
after the group. All entries specified in the group will be marked
immutable and no new entries can be added to the group
Example:
[MyGroup][$i]
someKey=42
- On a file by file basis by starting the file with
[$i]
Example:
[$i]
[MyGroup]
someKey=42
[MyOtherGroup]
- On a directory basis
[Not yet implemented]
The filesystem can also be used to mark files immutable. If
KDE does not have write-access to the user's version of a
configuration file, the file will be automatically considered
immutable.
Example:
chown root.root /home/user/.kde/share/config/kickerrc
chmod 644 /home/user/.kde/share/config/kickerrc
Note
This example is not fool-proof, the user can potentially still
rename either the root-owned kickerrc file or any of the directories in
the path to another name and create a new kickerrc _with_
write-access.
