|  | Home · Overviews · Examples

# QSettings Class Reference
[com.trolltech.qt.core module]

The `QSettings` class provides persistent platform-independent application settings. More...

Inherits `QObject`.

## Detailed Description

The `QSettings` class provides persistent platform-independent application settings.

Users normally expect an application to remember its settings (window sizes and positions, options, etc.) across sessions. This information is often stored in the system registry on Windows, and in XML preferences files on Mac OS X. On Unix systems, in the absence of a standard, many applications (including the KDE applications) use INI text files.

`QSettings` is an abstraction around these technologies, enabling you to save and restore application settings in a portable manner. It also supports custom storage formats.

`QSettings`'s API is based on `QVariant`, allowing you to save most value-based types, such as `QString`, `QRect`, and `QImage`, with the minimum of effort.

If all you need is a non-persistent memory-based structure, consider using QMap<`QString`, `QVariant`> instead.

- Basic Usage
- QVariant and GUI Types
- Key Syntax
- Fallback Mechanism
- Restoring the State of a GUI Application
- Accessing Settings from Multiple Threads or Processes Simultaneously
- Platform-Specific Notes

### Basic Usage

When creating a `QSettings` object, you must pass the name of your company or organization as well as the name of your application. For example, if your product is called Star Runner and your company is called MySoft, you would construct the `QSettings` object as follows:

            QSettings settings("MySoft", "Star Runner");

`QSettings` objects can be created either on the stack or on the heap (i.e. using `new`). Constructing and destroying a `QSettings` object is very fast.

If you use `QSettings` from many places in your application, you might want to specify the organization name and the application name using QCoreApplication::setOrganizationName() and QCoreApplication::setApplicationName(), and then use the default `QSettings` constructor:

            QCoreApplication::setOrganizationName("MySoft");
            QCoreApplication::setOrganizationDomain("mysoft.com");
            QCoreApplication::setApplicationName("Star Runner");
            ...
            QSettings settings;

(Here, we also specify the organization's Internet domain. When the Internet domain is set, it is used on Mac OS X instead of the organization name, since Mac OS X applications conventionally use Internet domains to identify themselves. If no domain is set, a fake domain is derived from the organization name. See the Platform-Specific Notes below for details.)

`QSettings` stores settings. Each setting consists of a `QString` that specifies the setting's name (the key) and a `QVariant` that stores the data associated with the key. To write a setting, use `setValue`. For example:

            settings.setValue("editor/wrapMargin", 68);

If there already exists a setting with the same key, the existing value is overwritten by the new value. For efficiency, the changes may not be saved to permanent storage immediately. (You can always call `sync` to commit your changes.)

You can get a setting's value back using `value`:

            int margin = settings.value("editor/wrapMargin").toInt();

If there is no setting with the specified name, `QSettings` returns a null `QVariant` (which can be converted to the integer 0). You can specify another default value by passing a second argument to `value`:

            int margin = settings.value("editor/wrapMargin", 80).toInt();

To test whether a given key exists, call `contains`. To remove the setting associated with a key, call `remove`. To obtain the list of all keys, call `allKeys`. To remove all keys, call `clear`.

### QVariant and GUI Types

Because `QVariant` is part of the `QtCore` library, it cannot provide conversion functions to data types such as `QColor`, `QImage`, and `QPixmap`, which are part of `QtGui`. In other words, there is no `toColor()`, `toImage()`, or `toPixmap()` functions in `QVariant`.

Instead, you can use the QVariant::value() or the qVariantValue() template function. For example:

        QSettings settings("MySoft", "Star Runner");
        QColor color = settings.value("DataPump/bgcolor").value<QColor>();

The inverse conversion (e.g., from `QColor` to `QVariant`) is automatic for all data types supported by `QVariant`, including GUI-related types:

        QSettings settings("MySoft", "Star Runner");
        QColor color = palette().background().color();
        settings.setValue("DataPump/bgcolor", color);

Custom types registered using qRegisterMetaType() and qRegisterMetaTypeStreamOperators() can be stored using `QSettings`.

### Key Syntax

Setting keys can contain any Unicode characters. The Windows registry and INI files use case-insensitive keys, whereas the Carbon Preferences API on Mac OS X uses case-sensitive keys. To avoid portability problems, follow these two simple rules:

1. Always refer to the same key using the same case. For example, if you refer to a key as "text fonts" in one place in your code, don't refer to it as "Text Fonts" somewhere else.
2. Avoid key names that are identical except for the case. For example, if you have a key called "`MainWindow`", don't try to save another key as "mainwindow".
3. Do not use slashes ('/' and '\') in key names; the backslash character is used to separate sub keys (see below). On windows '\' are converted by `QSettings` to '/', which makes them identical.

You can form hierarchical keys using the '/' character as a separator, similar to Unix file paths. For example:

            settings.setValue("mainwindow/size", win->size());
            settings.setValue("mainwindow/fullScreen", win->isFullScreen());
            settings.setValue("outputpanel/visible", panel->isVisible());

If you want to save or restore many settings with the same prefix, you can specify the prefix using `beginGroup` and call `endGroup` at the end. Here's the same example again, but this time using the group mechanism:

            settings.beginGroup("mainwindow");
            settings.setValue("size", win->size());
            settings.setValue("fullScreen", win->isFullScreen());
            settings.endGroup();

            settings.beginGroup("outputpanel");
            settings.setValue("visible", panel->isVisible());
            settings.endGroup();

If a group is set using `beginGroup`, the behavior of most functions changes consequently. Groups can be set recursively.

In addition to groups, `QSettings` also supports an "array" concept. See `beginReadArray` and `beginWriteArray` for details.

### Fallback Mechanism

Let's assume that you have created a `QSettings` object with the organization name MySoft and the application name Star Runner. When you look up a value, up to four locations are searched in that order:

1. a user-specific location for the Star Runner application
2. a user-specific location for all applications by MySoft
3. a system-wide location for the Star Runner application
4. a system-wide location for all applications by MySoft

(See Platform-Specific Notes below for information on what these locations are on the different platforms supported by Qt.)

If a key cannot be found in the first location, the search goes on in the second location, and so on. This enables you to store system-wide or organization-wide settings and to override them on a per-user or per-application basis. To turn off this mechanism, call `setFallbacksEnabled`(false).

Although keys from all four locations are available for reading, only the first file (the user-specific location for the application at hand) is accessible for writing. To write to any of the other files, omit the application name and/or specify QSettings::SystemScope (as opposed to QSettings::UserScope, the default).

Let's see with an example:

            QSettings obj1("MySoft", "Star Runner");
            QSettings obj2("MySoft");
            QSettings obj3(QSettings::SystemScope, "MySoft", "Star Runner");
            QSettings obj4(QSettings::SystemScope, "MySoft");

The table below summarizes which `QSettings` objects access which location. "X" means that the location is the main location associated to the `QSettings` object and is used both for reading and for writing; "o" means that the location is used as a fallback when reading.

Locations | `obj1` | `obj2` | `obj3` | `obj4`
--- | --- | --- | --- | ---
1. User, Application | X |  |  |
2. User, Organization | o | X |  |
3. System, Application | o |  | X |
4. System, Organization | o | o | o | X

The beauty of this mechanism is that it works on all platforms supported by Qt and that it still gives you a lot of flexibility, without requiring you to specify any file names or registry paths.

If you want to use INI files on all platforms instead of the native API, you can pass QSettings::IniFormat as the first argument to the `QSettings` constructor, followed by the scope, the organization name, and the application name:

            QSettings settings(QSettings::IniFormat, QSettings::UserScope,
                               "MySoft", "Star Runner");

The Settings Editor example lets you experiment with different settings location and with fallbacks turned on or off.

### Restoring the State of a GUI Application

`QSettings` is often used to store the state of a GUI application. The following example illustrates how to use we will use `QSettings` to save and restore the geometry of an application's main window.

        void MainWindow::writeSettings()
        {
            QSettings settings("Moose Soft", "Clipper");

            settings.beginGroup("MainWindow");
            settings.setValue("size", size());
            settings.setValue("pos", pos());
            settings.endGroup();
        }

        void MainWindow::readSettings()
        {
            QSettings settings("Moose Soft", "Clipper");

            settings.beginGroup("MainWindow");
            resize(settings.value("size", QSize(400, 400)).toSize());
            move(settings.value("pos", QPoint(200, 200)).toPoint());
            settings.endGroup();
        }

See Window Geometry for a discussion on why it is better to call QWidget::resize() and QWidget::move() rather than QWidget::setGeometry() to restore a window's geometry.

The `readSettings()` and `writeSettings()` functions must be called from the main window's constructor and close event handler as follows:

        MainWindow::MainWindow()
        {
            ...
            readSettings();
        }

        void MainWindow::closeEvent(QCloseEvent *event)
        {
            if (userReallyWantsToQuit()) {
                writeSettings();
                event->accept();
            } else {
                event->ignore();
            }
        }

See the Application example for a self-contained example that uses `QSettings`.

### Accessing Settings from Multiple Threads or Processes Simultaneously

`QSettings` is reentrant. This means that you can use distinct `QSettings` object in different threads simultaneously. This guarantee stands even when the `QSettings` objects refer to the same files on disk (or to the same entries in the system registry). If a setting is modified through one `QSettings` object, the change will immediately be visible in any other `QSettings` objects that operate on the same location and that live in the same process.

`QSettings` can safely be used from different processes (which can be different instances of your application running at the same time or different applications altogether) to read and write to the same system locations. It uses advisory file locking and a smart merging algorithm to ensure data integrity. Changes performed by another process aren't visible in the current process until `sync` is called.

### Platform-Specific Notes

#### Locations Where Application Settings Are Stored

As mentioned in the Fallback Mechanism section, `QSettings` stores settings for an application in up to four locations, depending on whether the settings are user-specific or system-wide and whether the the settings are application-specific or organization-wide. For simplicity, we're assuming the organization is called MySoft and the application is called Star Runner.

On Unix systems, if the file format is `NativeFormat`, the following files are used by default:

1. `$HOME/.config/MySoft/Star Runner.conf`
2. `$HOME/.config/MySoft.conf`
3. `/etc/xdg/MySoft/Star Runner.conf`
4. `/etc/xdg/MySoft.conf`

On Mac OS X versions 10.2 and 10.3, these files are used by default:

1. `$HOME/Library/Preferences/com.MySoft.Star Runner.plist`
2. `$HOME/Library/Preferences/com.MySoft.plist`
3. `/Library/Preferences/com.MySoft.Star Runner.plist`
4. `/Library/Preferences/com.MySoft.plist`

On Windows, `NativeFormat` settings are stored in the following registry paths:

1. `HKEY_CURRENT_USER\Software\MySoft\Star Runner`
2. `HKEY_CURRENT_USER\Software\MySoft`
3. `HKEY_LOCAL_MACHINE\Software\MySoft\Star Runner`
4. `HKEY_LOCAL_MACHINE\Software\MySoft`

If the file format is `IniFormat`, the following files are used on Unix and Mac OS X:

1. `$HOME/.config/MySoft/Star Runner.ini`
2. `$HOME/.config/MySoft.ini`
3. `/etc/xdg/MySoft/Star Runner.ini`
4. `/etc/xdg/MySoft.ini`

On Windows, the following files are used:

1. `%APPDATA%\MySoft\Star Runner.ini`
2. `%APPDATA%\MySoft.ini`
3. `%COMMON_APPDATA%\MySoft\Star Runner.ini`
4. `%COMMON_APPDATA%\MySoft.ini`

The `%APPDATA%` path is usually `C:\Documents and Settings\User Name\Application Data`; the `%COMMON_APPDATA%` path is usually `C:\Documents and Settings\All Users\Application Data`.

The paths for the `.ini` and `.conf` files can be changed using `setPath`. On Unix and Mac OS X, the user can override them by by setting the `XDG_CONFIG_HOME` environment variable; see `setPath` for details.

#### Accessing INI and .plist Files Directly

Sometimes you do want to access settings stored in a specific file or registry path. On all platforms, if you want to read an INI file directly, you can use the `QSettings` constructor that takes a file name as first argument and pass QSettings::IniFormat as second argument. For example:

        QSettings settings("/home/petra/misc/myapp.ini",
                           QSettings::IniFormat);

You can then use the `QSettings` object to read and write settings in the file.

On Mac OS X, you can access XML-based `.plist` files by passing QSettings::NativeFormat as second argument. For example:

        QSettings settings("/Users/petra/misc/myapp.plist",
                           QSettings::NativeFormat);

#### Accessing the Windows Registry Directly

On Windows, `QSettings` also lets you access arbitrary entries in the system registry. This is done by constructing a `QSettings` object with a path in the registry and QSettings::NativeFormat. For example:

        QSettings settings("HKEY_CURRENT_USER\\Software\\Microsoft\\Office",
                           QSettings::NativeFormat);

All the registry entries that appear under the specified path can be read or written through the `QSettings` object as usual (using forward slashes instead of backslashes). For example:

        settings.setValue("11.0/Outlook/Security/DontTrustInstalledFiles", 0);

Note that the backslash character is, as mentioned, used by `QSettings` to separate subkeys. As a result, you cannot read or write windows registry entries that contain slashes or backslashes; you should use a native windows API if you need to do so.

#### Accessing Common Registry Settings on Windows

On windows, it is possible for a key to have both a value and subkeys. Its default value is accessed by using "Default" or "." in place of a subkey:

        settings.setValue("HKEY_CURRENT_USER\\MySoft\\Star Runner\\Galaxy", "Milkyway");
        settings.setValue("HKEY_CURRENT_USER\\MySoft\\Star Runner\\Galaxy\\Sun", "OurStar");
        settings.value("HKEY_CURRENT_USER\\MySoft\\Star Runner\\Galaxy\\Default"); // returns "Milkyway"

On other platforms than windows, "Default" and "." would be treated as regular subkeys.

#### Platform Limitations

While `QSettings` attempts to smooth over the differences between the different supported platforms, there are still a few differences that you should be aware of when porting your application:

- The Windows system registry has the following limitations: A subkey may not exceed 255 characters, an entry's value may not exceed 16,383 characters, and all the values of a key may not exceed 65,535 characters. One way to work around these limitations is to store the settings using the `IniFormat` instead of the `NativeFormat`.
- On Mac OS X, `allKeys` will return some extra keys for global settings that apply to all applications. These keys can be read using `value` but cannot be changed, only shadowed. Calling `setFallbacksEnabled`(false) will hide these global settings.
- On Mac OS X, the CFPreferences API used by `QSettings` expects Internet domain names rather than organization names. To provide a uniform API, `QSettings` derives a fake domain name from the organization name (unless the organization name already is a domain name, e.g. OpenOffice.org). The algorithm appends ".com" to the company name and replaces spaces and other illegal characters with hyphens. If you want to specify a different domain name, call QCoreApplication::setOrganizationDomain(), QCoreApplication::setOrganizationName(), and QCoreApplication::setApplicationName() in your `main()` function and then use the default `QSettings` constructor. Another solution is to use preprocessor directives, for example:

          #ifdef Q_WS_MAC
              QSettings settings("grenoullelogique.fr", "Squash");
          #else
              QSettings settings("Grenoulle Logique", "Squash");
          #endif

See also `QVariant`, `QSessionManager`, Settings Editor Example, and Application Example.