| Age | Commit message (Collapse) | Author |
|---|
|
Otherwise they stick around when deleting actual settings (e.g. at logout).
|
|
Those stand for a boolean false value in Qt.labs.Settings, but plain JavaScript thinks that "false" == true so if you take a value through QMatrixClient::Settings instead of Qt.labs.Settings, you would get screwed.
|
|
This is for a case of renaming an organisation or an application
|
|
LoginJob
This is _almost_ a backwards-compatible change, except that connect*()
and other relevant methods in Connection are no more virtual (that
wasn't much useful anyway). Otherwise it's a matter of passing
initial_device_name to connectToServer(), saving device_id (along with
access_token) from the result of LoginJob and then passing device_id
(along with access_token, again) to connectWithToken() upon the next run.
|
|
This greatly reduces the noise made by quaternion.
To enable full logging, export the following variable:
QT_LOGGING_RULES="libqmatrixclient.*.debug=true"
|
|
Settings is a trivial wrapper around QSettings that makes value() and setValue() available from QML (Tensor has the same class atm). SettingsGroup is a cleaner way to reach for sections inside QSettings. It doesn't refer to another QSettings class, rather derives from it and overrides functions that deal with groups. AccountSettings, contrary to the two above, is by no means generic: it serves the specific purpose of storing settings of a single account in a uniform way. Rationale of it is that key literals like "keep_logged_in" cannot be enforced, while function names can; and the same goes for QVariants stored inside - the class enforces specific types while allowing further extension by clients.
Note that functions in QSettings are not virtual, so all these classes are not polymorphic.
|
