|
|
| (42 intermediate revisions by 18 users not shown) |
| Line 1: |
Line 1: |
| {{TutorialBrowser|
| | This tutorial was updated and moved to https://develop.kde.org/docs/features/configuration/introduction/ |
|
| |
|
| series=KConfig|
| | [[Category:MovedDevelop]] |
| | |
| name=Introduction to KConfig|
| |
| | |
| next=[[../Using_KConfig_XT|Using KConfig XT]]
| |
| | |
| }}
| |
| | |
| == Abstract ==
| |
| | |
| This tutorial looks at the KDE configuration data system, starting with an overview of the design fundamentals from an application developer's point of view. It then looks at the classes relevant to application development one by one before moving on to kiosk (user and group profiles) integration.
| |
| | |
| == Design Essentials ==
| |
| | |
| KConfig is designed to abstract away the concept of actual storage and retrieval of configuration settings behind an API that allows easy fetching and setting of information. Where and in what format the data is stored is not relevant to an application using KConfig. This keeps all KDE applications consistent in their handling of configurations while alleviating each and every application author to build such a system on their own from scratch, which is can be a highly error prone exercise.
| |
| | |
| A KConfig object represents a single configuration object. Each configuration object is referenced by its unique name and may be actually read from multiple local or remote files or services. Each application has a default configuration object associated with it and there is also a global configuration object.
| |
| | |
| These configuration objects are broken down into a two level hierarchy: groups and keys. A configuration object can have any number of groups and each group can have one or more keys with associated values.
| |
| | |
| Values stored may be of any number of data types. They are stored and retreived as the objects themselves. For example, a {{qt|QColor}} object is passed to a config object directly when storing a color value and when retreived a {{qt|QColor}} object is returned. Applications themselves therefore generally do not have to perform serialization and deserialization of objects themselves.
| |
| | |
| == The KConfig Class ==
| |
| | |
| The {{class|KConfig}} class is used to access a given configuration object. There are a number of ways to create a config object:
| |
| | |
| <code cppqt n>
| |
| // a plain old read/write config object
| |
| KConfig config("myapprc");
| |
| | |
| // a specific file in the filesystem
| |
| // currently must be an INI style file
| |
| KConfig fullPath("/etc/kderc");
| |
| | |
| // outside the standard config resource
| |
| KConfig dataResource("data", "myapp/somefile");
| |
| | |
| // not merged with global values
| |
| KConfig globalFree("localsrc", KConfig::NoGlobals);
| |
| | |
| // not merged with globals or the $KDEDIRS hierarchy
| |
| KConfig simpleConfig("simplerc",
| |
| KConfig::NoGlobals | KConfig::LocalOnly);
| |
| </code>
| |
