Move kconfig code to the root directory.

2 files changed, 1041 insertions, 0 deletions

diff --git a/docs/DESIGN.kconfig b/docs/DESIGN.kconfig
new file mode 100644
index 00000000..1aa0a3f8
--- /dev/null
+++ b/docs/DESIGN.kconfig
@@ -0,0 +1,224 @@
+kconfigdata.h contains definitions of the data formats used by kconfig.
+
+Configuration entries are stored as "KEntry". They are indexed with "KEntryKey".
+The primary store is a "KEntryMap" which is defined as a QMap from "KEntryKey"
+to "KEntry"
+
+KEntry's are stored in order in the KEntryMap. The most significant sort 
+criteria is mGroup. This means that all entries who belong in the same group,
+are grouped in the QMap as well. 
+
+The start of a group is indicated with a KEntryKey with an empty mKey and a 
+dummy KEntry. This allows us to search for the start of the group and then to 
+iterate until we end up in another group. That way we will find all entries
+of a certain group.
+
+Entries that are localised with the _current_ locale are stored with bLocal 
+set to true. Entries that are localised with another locale are either not
+stored at all (default), or with the localization as part of the key (when
+reading a file in order to merge it). 
+[WABA: Does it make sense to keep both localized and non-localised around?
+Can't we just let the localised version override the non-localised version?]
+
+Currently the localization bit is the least significant sort criteria, that 
+means that the localised version always follows the non-localised version
+immediately.
+
+<Changed for KDE 3.0>
+Entries that are being read from a location other than the location to
+which is written back are marked as "default" and will be added both as
+normal entry as well as an entry with the key marked as default.
+
+When entries are written to disk, it is checked whether the entry to write 
+is equal to the default, if so the entry will not be written. The default
+entry always follows directly after the normal entry, due to the sorting.
+(After that the localised version follows)
+
+When entries are written to disk, it is checked whether the entry to write 
+is equal to the default, if so the entry will not be written.
+</Changed>
+
+Open question:
+Should unmodified entries that are written back be compared with the default
+too? This seems to be mostly a transition issue.
+
+<Changed during KDE 3.0 / 3.2>
+Extra functions:
+
+bool isEntryImmutable(key); // Can entry be modified?
+bool hasDefault(key); // Is there a system wide default set for the entry?
+void revertToDefault(key); // Restore to default
+void deleteEntry(key); // Remove entry
+
+Note that there is a subtle difference between revertToDefault() and deleteEntry().
+revertToDefault() will change the entry to the default value set by the system 
+administrator (Via e.g. $KDEDIR/share/config) or, if no such default was set,
+non-existant.
+deleteEntry() will make the entry non-existant.
+
+Entries are marked "immutable" if the key is followed by [$i]. This means
+that a user can not override these entries.
+
+Entries can be marked as deleted if they are followed by [$d]. This
+is needed if the system administrator has specified a default value but the
+entry was deleted (made 'non-existant'). In that case we can't just leave 
+the entry out since that would mean we get the default from the system 
+administrator back the next time we read the file.
+</changed>
+
+When an entry is read with readEntry(key, defaultValue), non-existing
+entries will return "defaultValue" while hasKey(key) will return "false"
+for such entries.
+
+Currently all entries are stored in memory. When KConfig is "sync()'ed"
+it reads the file that it is about to overwrite (for the second time), it 
+then merges in the entries it has in memory and writes the result back to 
+the file. It does NOT update its map of entries in memory with the entries
+(re)read from disk. It only updates the entries in memory when 
+"reparseConfiguration()" is called.
+
+
+Open Question: The standard writeEntry() function returns the original value,
+is this needed? Nobody seems to use it. 
+
+Open Question: The bPersistent flag doesn't seem to be used... could it be removed?
+
+Open Question: Is the bNLS flag needed? Localised entries seem to be mostly
+useful for default files, are they ever created by the user itself?
+
+Open Question: Would it be worthwhile to lock a user option that is equal to the 
+default so that it doesn't change when the default changes?
+
+
+KDE3.0 Changes
+==============
+
+*) writeEntry now returns void instead of QString.
+*) deleteEntry functions added
+
+
+------------------------------------------------------------------------------
+
+KConfig XT
+==========
+
+My buzzword picker offered KConfig XT ("eXtended Technology") and KConfig NG 
+("Next Generation").  Since the planned changes are ment to be evolutionary 
+rather than revolutionary, KConfig NG was dropped.
+
+Goals
+=====
+
+* Have the default value for config entries defined in 1 place. Currently it is
+not uncommon to have them defined in three places:
+  1) In the application that reads the setting in order to use it
+  2) In the settings dialog when reading the setting
+  3) In the settings dialog when selecting "Use defaults".
+
+* Provide type-information about config entries to facilate "KConfEdit" like 
+tools. Ideally type-information also includes range-information; this is even
+mandatory if enums become an explicit type.
+
+* Facilitate the documentation of config entries.
+
+
+Instead of relying on the defaults that are hard-coded in the application, 
+rely on default configuration files being installed in $KDEDIR. The technical
+changes required for this are very minimal, it is mostly a change in policy.
+
+Type information can be provide by preceding every entry with a formalized 
+comment.
+
+Work to be done:
+* KConfig needs to be extended to provide access to the default values provided 
+by the default config files. KConfig already stores this information internally.
+(DONE)
+* A formal comment structure needs to be designed that can convey type-information.
+Preferably in such a way that it is easily parsable by both machine and user.
+* KConfig needs to be extended, or another class created, that is able to parse
+the formalized comments.
+* A tool needs to be developed that can assist developers with the generation
+and verification of default configuration files including type-information.
+
+Drawbacks:
+* We rely on default configuration files being properly installed. 
+* The user can break applications by making improper modifications to these 
+files.
+* It is not possible to store defaults settings in a config file that are 
+of a dynamic nature. Examples are settings derived from other settings, 
+e.g. a color setting could be derived from the current color theme, or
+e.g. the default high score user name which is determined by the user
+currently logged in.
+
+
+Some random ideas:
+* The format of the entries would be something like this:
+
+[Mail Settings]
+#!Type=string
+#!Description=SMTP server to use for sending mail
+#!Description[nl]=SMTP server voor het versturen van mail
+Host=wantelbos.zogje.fr
+
+- the type could be subclassed more, e.g. strings can be "email", "hostname",
+  "url", etc.
+
+- having translations in these files is very arguable. external po's would be
+  better.
+
+
+
+Class overview
+
+                       KConfigBase
+                            |
+                            v
+ KConfigBackend  <-----> KConfig <------> KConfigSkeleton           /--< myapp.kcfg
+       |                    |                    |                 /
+       v                    v                    |*---------------<
+KConfigINIBackend      KSimpleConfig             |kconfig_compiler \
+                                                 |                  \--< myconfig.kcfg-codegen
+                                                 v                                                    
+                                             MyConfig <-----KConfigDialogManager----> MyConfigWidget *---< myconfigwidget.ui
+                                                                                                      uic
+
+KConfigBase: defines API for generic config class
+
+KConfig: functional generic config class that supports merging of cascaded
+         configuration files
+
+KSimpleConfig: functional generic config class without support for cascading
+               configuration files.
+
+KConfigBackend: defines API for config backend, t.i. the actual handling
+                of the storage method and storage format.
+
+KConfigINIBackend: the standard (and only one so far) class that implements
+                   the config backend using the file-based .INI format
+                   for configuration files
+
+KConfigSkeleton: base class for deriving classes that store application
+                 specific options providing type-safety and single-point
+                 defaults.
+
+MyConfig: An application specific class that offers configuration options
+          to the applications via variables or accessor functions and that
+          handles type-safety and defaults. MyConfig is just an example
+          name, the application developer choses the actual name.
+
+myapp.kcfg: File describing the configuration options used by a specific
+            application. myapp.kcfg is just an example name, the application
+            developer choses the actual name.
+
+myconfig.kcfg-codegen: Implementation specific code generation instructions
+                       for the MyConfig class. myconfig.kcfg-codegen is
+                       just an example name, the application developer
+                       choses the actual name.
+
+KConfigDialogManager: Class that links widgets in a dialog up with their
+                      corresponding confguration options in a configuration
+                      object derived from KConfigSkeleton.
+
+MyConfigWidget: Dialog generated from a .ui description file. Widget names
+                in the dialog that start with "kcfg_" refer to configuration
+                options.
diff --git a/docs/README.kiosk b/docs/README.kiosk
new file mode 100644
index 00000000..4974acef
--- /dev/null
+++ b/docs/README.kiosk
@@ -0,0 +1,817 @@
+In KDE-3 a kiosk-framework has been introduced.
+
+One 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 application API that applications can query to get authorisation
+for certain operations.
+
+The KDE kiosk-framework should be used IN ADDITION to the standard UNIX
+security measures.
+
+The configuration framework in KDE
+==================================
+
+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 were located under $KDEDIR and user-
+specific resources were 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/kde4rc 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. KDE 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 configuration files that are
+read later will not be able to override its value. Immutable entries cannot
+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]
+someOtherKey=11
+
+- 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.
+
+To make the configuration file of Dolphin immutable one could for
+example use the commands below.
+
+Example:
+chown root.root /home/user/.kde/share/config/dolphinrc
+chmod 644 /home/user/.kde/share/config/dolphinrc
+
+If you do this, the user will be warned that the configuration file is not
+writable. Since you will normally not want that, you can add the following
+two lines to the application's configuration file (or to kdeglobals to
+disable the warning for all applications):
+
+[KDE Action Restrictions]
+warn_unwritable_config=true
+
+Note that the above example is not fool-proof, the user can potentially still
+rename either the root-owned dolphinrc file or any of the directories in
+the path to another name and create a new dolphinrc _with_ write-access.
+
+KDE Action Restrictions
+=======================
+
+Most functionality within KDE is coupled to so called actions. For example when a user
+selects the File->Open option in the menubar of a KDE application, the "file_open"
+action is activated. Likewise, toolbar icons are usually also coupled to actions. KDE
+makes it possible to disable functionality by restricting specific actions. By restricting the
+"file_open" action for example, the corresponding entry in the menubar and the corresponding icon on
+the toolbar, if any, will disappear.
+
+To restrict access to function the kdeglobals file should contain the
+group "[KDE Action Restrictions]", each action can then be restricted by
+adding "<action>=false". E.g. to disable the action "shell_access" one
+would add:
+[KDE Action Restrictions][$i]
+shell_access=false
+
+Actions that refer to menu and toolbar actions are prefixed with 'action/'.
+The following standard actions are defined:
+
+action/file_new
+action/file_open
+action/file_open_recent
+action/file_save
+action/file_save_as
+action/file_revert
+action/file_close
+action/file_print
+action/file_print_preview
+action/file_mail
+action/file_quit
+action/edit_undo
+action/edit_redo
+action/edit_cut
+action/edit_copy
+action/edit_paste
+action/edit_select_all
+action/edit_deselect
+action/edit_find
+action/edit_find_next
+action/edit_find_last
+action/edit_replace
+action/view_actual_size
+action/view_fit_to_page
+action/view_fit_to_width
+action/view_fit_to_height
+action/view_zoom_in
+action/view_zoom_out
+action/view_zoom
+action/view_redisplay
+action/go_up
+action/go_back
+action/go_forward
+action/go_home
+action/go_previous
+action/go_next
+action/go_goto
+action/go_goto_page
+action/go_goto_line
+action/go_first
+action/go_last
+action/bookmarks // See note below
+action/bookmark_add
+action/bookmark_edit
+action/tools_spelling
+action/options_show_menubar
+action/options_show_toolbar  // See note below
+action/options_show_statusbar
+action/options_save_options
+action/options_configure
+action/options_configure_keybinding
+action/options_configure_toolbars
+action/options_configure_notifications
+action/help // See note below
+action/help_contents
+action/help_whats_this
+action/help_report_bug
+action/help_about_app
+action/help_about_kde
+action/fullscreen
+
+Actions in the KDE File Dialog:
+action/home		// Go to home directory
+action/up		// Go to parent directory
+action/back		// Go to previous directory
+action/forward		// Go to next directory
+action/reload		// Reload directory
+action/mkdir		// Create new directory
+action/toggleSpeedbar	// Show/hide sidebar
+action/sorting menu	// Sorting options
+action/short view	// Select short view
+action/detailed view	// Select detailed view
+action/show hidden	// Show/hide hidden files
+action/preview		// Show/hide preview
+action/separate dirs	// Show/hide separate directories
+
+
+Konqueror & KDesktop related:
+action/editfiletype
+action/properties
+action/openwith
+action/openintab
+action/kdesktop_rmb // RMB menu, see note below
+action/iconview_preview
+action/sharefile // File sharing, see note below
+action/sendURL // Send Link Address
+action/sendPage // Send File
+action/devnew // Create New -> Device
+action/incIconSize // Increase icon size
+action/decIconSize // Decrease icon size
+action/go // Entire go menu
+action/configdesktop // Configure desktop in RMB menu, see also Control Module Restrictions
+action/executeshellcommand // In Konqueror Tools menu, see also shell_access
+action/show_dot // Show Hidden Files, see note below
+
+
+Kicker related:
+action/kicker_rmb // RMB menu
+action/menuedit
+
+
+KWin related:
+action/kwin_rmb // RMB window context menu
+
+Konsole related:
+action/konsole_rmb // RMB context menu
+
+action/settings // Entire settings menu
+action/show_menubar
+action/show_toolbar
+action/scrollbar
+action/fullscreen
+action/bell
+action/font
+action/keyboard
+action/schema
+action/size
+action/history
+action/save_default
+action/save_sessions_profile
+action/options_configure_notifications
+action/options_configure_keybinding
+action/options_configure
+
+action/send_signal
+action/bookmarks
+action/add_bookmark
+action/edit_bookmarks
+action/clear_terminal
+action/reset_clear_terminal
+action/find_history
+action/find_next
+action/find_previous
+action/save_history
+action/clear_history
+action/clear_all_histories
+action/detach_session
+action/rename_session
+action/zmodem_upload
+action/monitor_activity
+action/monitor_silence
+action/send_input_to_all_sessions
+action/close_session
+action/new_session
+action/activate_menu
+action/list_sessions
+action/move_session_left
+action/move_session_right
+action/previous_session
+action/next_session
+action/switch_to_session_1
+action/switch_to_session_2
+action/switch_to_session_3
+action/switch_to_session_4
+action/switch_to_session_5
+action/switch_to_session_6
+action/switch_to_session_7
+action/switch_to_session_8
+action/switch_to_session_9
+action/switch_to_session_10
+action/switch_to_session_11
+action/switch_to_session_12
+action/bigger_font
+action/smaller_font
+action/toggle_bidi
+
+
+
+Notes:
+* action/options_show_toolbar will also disable the "Toolbars" submenu
+  if present.
+* action/bookmarks also disables action/bookmark_add and action/bookmark_edit
+* action/help is not yet fully implemented
+* action/kdesktop_rmb disables the RMB menu but some actions may still be accesible
+  via keyboard shortcuts: cut/copy/rename/trash/delete
+* action/iconview_preview disables the option to toggle previews on or off
+  in icon mode but the actual preview settings remains unaffected.
+  To disable previews you also need to add the following lines to
+  konqiconviewrc:
+	[Settings]
+	PreviewsEnabled[$i]=false
+* action/show_dot disables the option to toggle showing hidden files, the actual
+  setting remains unaffected.
+  To disable showing hidden files, add the following lines to konqiconviewrc:
+	[Settings]
+	ShowDotFiles[$i]=false
+* action/sharefile disables file sharing from the UI, but you may also want
+  to disable filesharing altogether.
+
+
+Applications may use additional actions that they defined themselves.
+You can get a list of the actions used by a certain applications by using the
+following qdbus command:
+
+qdbus org.kde.myapp-id | grep actions | cut -d '/' -f 4,5
+
+Actions that refer to applications that need to be run as a different user
+are prefixed by user/ and identified by the username. For example:
+
+user/root=false
+
+will disable all application entries that require root access.
+
+
+Printing related action restrictions:
+
+print/system
+        - disables the option to select the printing system (backend). It is
+          recommended to  disable this option once the correct printing
+          system has been configured.
+
+print/properties
+        - disables the button to change printer properties or to add a new printer.
+
+print/options
+        - disables the button to select additional print options.
+
+print/copies
+        - disables the panel that allows users to make more than one copy.
+
+print/selection
+        - disables the options that allows selecting a (pseudo) printer or
+          change any of the printer properties. Make sure that a proper
+          default printer has been selected before disabling this option.
+          Disabling this option also disables print/system, print/options
+          and print/properties.
+
+print/dialog
+        - disables the complete print dialog. Selecting the print option will
+          immediately print the selected document using default settings.
+          Make sure that a system wide default printer has been selected.
+          No application specific settings are honored.
+
+Other defined actions:
+
+shell_access
+        - defines whether a shell suitable for entering random commands
+          may be started. This also determines whether the "Run Command"
+          option (Alt-F2) can be used to run shell-commands and arbitrary
+          executables. Likewise, executables placed in the user's
+          Autostart folder will no longer be executed. Applications can
+          still be autostarted by placing .desktop files in the $KDEHOME/Autostart
+          or $KDEDIR/share/autostart directory.
+          See also run_desktop_files.
+
+custom_config
+        - defines whether the --config command line option should be honored.
+          The --config command line option can be used to circumvent
+          locked-down configuration files.
+
+logout
+        - defines whether the user will be able to logout from KDE.
+
+lock_screen
+        - defines whether the user will be able to lock the screen.
+
+run_command
+        - defines whether the "Run Command" (Alt-F2) option is available.
+
+movable_toolbars
+        - define whether toolbars may be moved around by the user.
+          See also action/options_show_toolbar.
+
+editable_desktop_icons
+        - define whether icons on the desktop can be moved, renamed,
+          deleted or added. You might want to set the path for
+          the Desktop to some read-only directory as well.
+          (Instead of $HOME/Desktop)
+
+run_desktop_files
+        - defines whether users may execute desktop files that are not
+          part of the default desktop, KDE menu, registered services and
+          autostarting services.
+          * The default desktop includes the files under
+            $KDEDIR/share/kdesktop/Desktop but _NOT_ the files under
+            $HOME/Desktop.
+          * The KDE menu includes all files under $KDEDIR/share/applnk and
+            $XDGDIR/applications
+          * Registered services includes all files under $KDEDIR/share/services.
+          * Autostarting services include all files under $KDEDIR/share/autostart
+            but _NOT_ the files under $KDEHOME/Autostart
+
+          You probably also want to activate the following resource
+          restictions:
+          "appdata_kdesktop" - To restrict the default desktop.
+          "apps" - To restrict the KDE menu.
+          "xdgdata-apps" - To restrict the KDE menu.
+          "services" - To restrict registered services.
+          "autostart" - To restrict autostarting services.
+          Otherwise users can still execute .desktop files by placing them
+          in e.g. $KDEHOME/share/kdesktop/Desktop
+
+lineedit_text_completion
+        - defines whether input lines should have the potential to remember
+          any previously entered data and make suggestions based on this
+          when typing. When a single account is shared by multiple people you
+          may wish to disable this out of privacy concerns.
+
+start_new_session
+	- defines whether the user may start a second X session.
+          See also the kdm configuration.
+
+switch_user
+        - defines whether user switching via kdm is allowed
+
+skip_drm
+	- defines if the user may omit DRM checking.
+          Currently only used by kpdf
+
+Screensaver related:
+opengl_screensavers
+	- defines whether OpenGL screensavers are allowed to be used.
+
+manipulatescreen_screensavers
+	- defines whether screensavers that manipulate an image of the screen
+	  (e.g. moving chunks of the screen around) are allowed to be used.
+
+When configuration files are marked immutable in whole or in part the user will no
+longer be able to make permanent changes to the settings that have been marked
+immutable. Ideally the application will recognize this and will no longer offer the
+user the possibility to change these settings. Unfortunately not all applications
+support this at the moment. It's therefor possible that the user will still be
+presented with an option in the user interface to change a setting that is
+immutable, changes made this way will not be saved though. In some cases the
+user may be able to use the changed setting till the application terminates, in
+other cases the changed setting will simply be ignored and the application will
+continue to work with the immutable setting.
+
+The following applications currently detect when their configuration files have been
+marked immutable and adjust their user interface accordingly:
+
+* kicker - By marking the kickerrc config file as immutable, the panel will be
+"locked down" and it will not be possible to make any changes to it.
+
+* kdesktop - By marking the kdesktoprc config file as immutable, the desktop
+will be "locked down" and it will no longer be possible to select
+"Configure Desktop" from its menus.
+
+* kcalc - By marking the kcalcrc config file as immutable, the "Configure" button
+will not be shown
+
+Application .desktop files can have an additional field "X-KDE-AuthorizeAction".
+If this field is present the .desktop file is only considered if the action(s)
+mentioned in this field has been authorized. If multiple actions are listed
+they should be separated by commas (','). So if the .desktop file of an application
+lists one or more actions this way and the user has no authorization for one
+of these actions then the application will not appear in the KDE menu and will not
+be used by KDE for opening files.
+
+IMPORTANT NOTE:
+Changing restrictions may influence the data that is cached in the ksycoca
+database. Since changes to .../share/config/kdeglobals do not trigger an
+automatic ksycoca update you need to force an update manually.
+To force an update of the ksycoca database touch the file
+.../share/services/update_ksycoca. This will force a user's sycoca database
+to be rebuild the next time the user logs in.
+
+KDE URL Restrictions
+====================
+
+It is also possible to restrict URL related actions. The restriction framework
+can disable URL actions based on the action, the URL in question and in some cases
+the referring URL. URLs can be matched based on protocol, host and path.
+
+The syntax for adding URL action restrictions to kdeglobals is as follows:
+
+[KDE URL Restrictions]
+rule_count=<N>
+rule_1=<action>,<referingURL_protocol>,<referingURL_host>,<referingURL_path>,<URL_protocol>,<URL_host>,<URL_path>,<enabled>
+...
+rule_N=<action>,<referingURL_protocol>,<referingURL_host>,<referingURL_path>,<URL_protocol>,<URL_host>,<URL_path>,<enabled>
+
+The following actions are supported:
+redirect - e.g. a html-page obtained via HTTP could redirect itself to file:/path/some-file. This
+           is disabled by default but could be explicitly enabled for a specific HTTP host.
+           This also applies to links contained in html documents.
+           Example: rule_1=redirect,http,myhost.acme.com,,file,,,true
+
+list     - This controls which directories can be browsed with KDE's file-dialogs. If a user
+           should only be able to browse files under home directory one could use:
+              rule_1=list,,,,file,,,false
+              rule_2=list,,,,file,,$HOME,true
+           The first rule disables browing any directories on the local filesystem. The second rule
+           then enables browsing the users home directory.
+
+open     - This controls which files can be opened by the user in applications. It also
+           affects where users can save files. To only allow a user to open the files
+           in his own home directory one could use:
+              rule_1=open,,,,file,,,false
+              rule_2=open,,,,file,,$HOME,true
+              rule_3=open,,,,file,,$TMP,true
+           Note that with the above, users would still be able to open files from
+           the internet. Note that the user is also given access to $TMP in order to
+           ensure correct operation of KDE applications. $TMP is replaced with the
+           temporary directory that KDE uses for this user.
+
+Some remarks:
+* empty entries match everything
+* host names may start with a wildcard, e.g. "*.acme.com"
+* a protocol also matches similar protocols that start with the same name,
+  e.g. "http" matches both http and https. You can use "http!" if you only want to
+  match http (and not https)
+* specifying a path matches all URLs that start with the same path. For better results
+  you should not include a trailing slash. If you want to specify one specific path, you can
+  add an exclamation mark. E.g. "/srv" matches both "/srv" and "/srv/www" but "/srv!" only
+  matches "/srv" and not "/srv/www".
+
+
+KDE Resource Restrictions
+==========================
+Most KDE applications make use of additional resource files that are typically
+located in directories under $KDEDIR/share. By default KDE allows users to
+override any of these resources by placing files in the same location
+under $KDEHOME/share. For example, Konsole stores profiles under
+$KDEDIR/share/konsole and users can add additional profiles by
+installing files in $KDEHOME/share/konsole.
+
+KDE Resource Restrictions make it possible to restrict the lookup of files
+to directories outside of $KDEHOME only.
+
+The following resources are defined:
+
+autostart - share/autostart
+data - share
+html - share/doc/HTML
+icon - share/icon
+config - share/config
+pixmap - share/pixmaps
+apps - share/applnk
+xdgdata-apps - share/applications
+sound - share/sounds
+locale - share/locale
+services - share/services
+servicetypes - share/servicetypes
+mime - share/mimelnk
+wallpaper - share/wallpapers
+templates - share/templates
+exe - bin
+lib - lib
+
+See http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKStandardDirs.html
+for a more up-to-date list of resources.
+
+For the purpose of resource restrictions there are two special resources:
+all - covers all resources
+data_<appname> - covers the sub section for <appname> in the data resource.
+
+To restrict resources the kdeglobals file should contain the
+group "[KDE Resource Restrictions]", each resource can then be restricted by
+adding "<resource>=false". E.g. to restrict the "wallpaper" resource to
+$KDEDIR/share/wallpapers one would add:
+[KDE Resource Restrictions][$i]
+wallpaper=false
+
+And to prevent a user from adding additional konsole profiles, one would add:
+[KDE Resource Restrictions][$i]
+data_konsole=false
+
+
+Control Module Restrictions
+===========================
+
+It is possible to restrict access to particular control modules.
+Although it is possible to remove control modules from the Control
+Center by editing the menu structure, such modules will then still
+be available to applications. A better way is to use the control
+module restrictions offered by KIOSK:
+
+[KDE Control Module Restrictions][$i]
+<menu-id>=false
+
+Some example menu-ids are:
+
+kde-display.desktop
+kde-proxy.desktop
+kde-screensaver.desktop
+
+See also kcmshell --list for a list of all the base names.
+
+Expansion of environment variables in KDE config files.
+=======================================================
+
+Since KDE-3.1, arbitrary entries in configuration files can contain environment
+variables. In order to use this the entry must be marked with [$e].
+
+Example:
+Name[$e]=$USER
+
+When the "Name" entry is read $USER will be replaced with the value of the
+$USER environment variable. Note that the application will replace $USER
+with the value of the environment variable after saving. To prevent this
+combine the $e option with $i (immmutable) option.
+
+Example:
+Name[$ei]=$USER
+
+The above will make that the "Name" entry will always return the value of
+the $USER environment variable. The user will not be able to change this entry.
+
+The following syntax is also supported:
+Name[$ei]=${USER}
+
+
+Shell Commands in KDE config files.
+===================================
+
+Since KDE-3.1 arbitrary entries in configuration files can contain shell
+commands. This way the value of a configuration entry can be determined
+dynamically at runtime. In order to use this the entry must be marked
+with [$e].
+
+Example:
+Host[$e]=$(hostname)
+
+
+KDE Kiosk Application API
+==========================
+
+Three new methods have been added to KApplication:
+
+- bool authorize(QString action); // Generic actions
+- bool authorizeKAction(QString action); // For KActions exclusively
+- bool authorizeURLAction(QString, referringURL, destinationURL) // URL Handling
+
+Automatic Logout
+================
+
+Since KDE 3.4 it is possible to automatically logout users that have been idle
+for a certain period of time.
+
+WARNING: Be careful with this option, logging out a user may result in dataloss!
+
+In kdesktoprc you can use the following entry to enable automatic logout:
+
+[ScreenSaver]
+AutoLogout=true
+AutoLogoutTimeout=600
+
+The AutoLogoutTimeout is the time in seconds that the user has to be idle before
+his session is logged out.
+
+
+Users can be associated with Profile(s)
+=======================================
+
+A user can be associated with one or more profiles. A profile indicates a
+configuration set that applies to a group of users. Each profile has a name
+to identify it. If a user is associated with more than one profile then the
+order of the two profiles is important. Settings associated with one profile
+could override the settings in the other profile, depending on the order.
+
+
+Mapping profiles to users
+=========================
+
+A mapping file determines which profile(s) should be used for which user.
+The mapping file can be configured in /etc/kde4rc in the [Directories] group:
+
+	[Directories]
+	userProfileMapFile=/etc/kde-user-profile
+
+Profiles can be mapped to individual users based on username, or profiles can
+be mapped to groups of users based on the UNIX group(s) the users are part of.
+(See man 1 groups)
+
+
+Mapping profiles to individual users
+====================================
+
+The mapping file can contain a [Users] section for mapping profiles to
+an individual user. The [Users] section contains the user's account name
+followed by one or more profiles as follow:
+
+	[Users]
+	bastian=developer
+	adrians=developer,packager
+
+The above example assigns to user "bastian" the profile "developer". To user
+"adrians" it assigns the two profiles "developer" and "packager". The order
+in which the profiles are listed makes a difference, settings in earlier
+profiles overrule settings in profiles that are listed after it. In the above
+case of user "adrians", wherever the "developer" and "packager" profiles contain
+conflicting settings, the settings of the "developer" profile will take precedent.
+
+If a user has an entry under the [Users] section, this entry will determine all
+profiles that are applicable to the user. The user will not be assigned any
+additional profiles based on the groups the user is part of.
+
+Mapping profiles to user groups
+===============================
+
+If a user has no entry under the [Users] section in the mapping file, the profiles
+that are applicable to the user will be based on the UNIX group(s) the user is
+part of.
+
+The groups and the order in which the groups are considered is determined by
+the following entry in the [General] section of the mapping file:
+
+	[General]
+	groups=pkgs,devel,bofh
+
+Each of these groups should have an entry under the [Groups] section that defines
+which profile(s) belongs to that group. This looks as follows:
+
+	[Groups]
+	pkgs=packager
+	devel=developer
+	bofh=admin,packager,developer
+
+For each group that a user is part of, the corresponding profile(s) are used. The
+order in which the groups are listed in the "groups" entry, determines the resulting
+order of all the applicable profiles. If multiple profiles are applicable to a
+particular user and a profile contains settings that conflict with settings in
+another profile then the settings in the earlier listed profile take precedent.
+
+So if, based on the example above, a user is part of the "pkgs" group then the
+"packager" profile will be used for that user. If the user is part of the "devel"
+group then the "developer" profile will be used. Users that are part of the "bofh"
+group will use the "admin", "packager" as well as the "developer" profile. In case
+of conflict, settings in the "admin" profile will take precedent over settings
+in the "packager" or "developer" profiles.
+
+If the user is part of both the "pkgs" and "devel" groups, then both the "packager"
+and "developer" profiles will be used. In case of conflicting settings between the
+two profiles, the "packager" profile will take precedent because the "pkgs" group
+associated with the profile was listed before the "devel" group.
+
+The "groups" command can be used to see to which groups a user belongs:
+
+	> groups coolo
+        coolo : users uucp dialout audio video cdrecording devel
+
+Note that in general only a few groups will have profiles associated with them.
+In the example above only the "devel" group has a profile associated with it,
+the other groups do not and will be ignored.
+
+If there is no profile defined for any of the groups that the user is in, the
+user will be assigned the "default" profile.
+
+
+The Profile determines the directory prefixes
+=============================================
+
+The global KDE configuration file (e.g. kdeglobals or /etc/kde4rc) can
+contain config-groups that are associated with a certain user profile.
+Such a config-group is treated similar as the [Directories] config-group.
+
+The name of a such config-group is [Directories-<ProfileName>]
+
+
+Integration with KIOSK Admin Tool
+=================================
+
+The KIOSK Admin Tool uses /etc/kde4rc as source for all its profile
+information. For this it uses the following keys in the
+[Directories-<ProfileName>] config-group:
+
+	# Short text describing this profile
+	ProfileDescription=
+
+	# Files will be installed with the uid of this user
+	ProfileInstallUser=
+
+The KIOSK Admin Tool uses the first directory from the prefixes= entry
+as default installation directory for this profile.
+
+
+Default setting as example
+==========================
+
+The following snipped could be added to /etc/kde4rc to define a "default" profile:
+
+	[Directories-default]
+	ProfileDescription=Default profile
+	ProfileDescription[de]=Defaultprofiel
+	ProfileInstallUser=root
+	prefixes=/var/run/kde-profile/default
+