QSettings Class▲
-
Header: QSettings
-
CMake:
find_package(Qt6 REQUIRED COMPONENTS Core)
target_link_libraries(mytarget PRIVATE Qt6::Core)
-
qmake: QT += core
-
Inherits: QObject
-
Group: QSettings is part of Input/Output and Networking
Detailed Description▲
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 property list files on macOS and iOS. 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▲
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 macOS and iOS instead of the organization name, since macOS and iOS 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 Qt Core module, it cannot provide conversion functions to data types such as QColor, QImage, and QPixmap, which are part of Qt GUI. In other words, there is no toColor(), toImage(), or toPixmap() functions in QVariant.
Instead, you can use the QVariant::value() template function. For example:
QSettings settings("MySoft"
, "Star Runner"
);
QColor color =
settings.value("DataPump/bgcolor"
).value&
lt;QColor&
gt;();
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() that have operators for streaming to and from a QDataStream can be stored using QSettings.
Section and Key Syntax▲
Setting keys can contain any Unicode characters. The Windows registry and INI files use case-insensitive keys, whereas the CFPreferences API on macOS and iOS uses case-sensitive keys. To avoid portability problems, follow these simple rules:
-
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.
-
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".
-
Do not use slashes ('/' and '\') in section or 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-&
gt;size());
settings.setValue("mainwindow/fullScreen"
, win-&
gt;isFullScreen());
settings.setValue("outputpanel/visible"
, panel-&
gt;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-&
gt;size());
settings.setValue("fullScreen"
, win-&
gt;isFullScreen());
settings.endGroup();
settings.beginGroup("outputpanel"
);
settings.setValue("visible"
, panel-&
gt;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:
-
a user-specific location for the Star Runner application
-
a user-specific location for all applications by MySoft
-
a system-wide location for the Star Runner application
-
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 |
&n |