[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kiosk
Subject:    [Kde-kiosk] Support for kiosk operation (Part 1)
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-10-15 19:36:38
[Download RAW message or body]

(Draft, Part 1)

In KDE3 a kiosk-framework will be introduced. 

On of the driving forces behind KDE is to put the user in control and
give him or her a large amount of possibilities to adjust KDE to his or her 
liking. However, in some situations it is required to reduce the possibilities
of KDE, e.g. because the system is to be used for one or more specific 
dedicated tasks only.

The kiosk-framework provides an easy way to disable certain features within
KDE to create a more controlled environment.

KDE's kiosk-framework builds on KDE's configuration framework and adds a
simple API that applications can query to get authorisation for certain 
operations.

The configuration framework in KDE3
===================================

Since the very beginning KDE makes use of file-hierarchy to store resources
for its applications. Resources range from icons, wallpapers, fonts to 
sounds, menu-descriptions and configuration files. 

In KDE1 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 KDE2 resource management has been largely abstracted by the introduction
of the KStandardDirs class and has become much more flexible. The user /
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 KDE1 and KDE2 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 KDE3 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. KDE3 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 KDE3, 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. [Not yet implemented]

- On a directory basis. [Not yet implemented]


In Part 2: KDE3 Authorisation API
-- 
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com

_______________________________________________
Kde-kiosk mailing list
Kde-kiosk@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-kiosk

[prev in list] [next in list] [prev in thread] [next in thread]