| Age | Commit message (Collapse) | Author |
|---|
|
It cannot be made in templates because property and methods names are involved.
|
|
Otherwise they stick around when deleting actual settings (e.g. at logout).
|
|
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.
|
|
|
|
|
|
|
|
VS2013 doesn't like 'using' statements if a base class has private constructors (as in QSettings - Q_DISABLE_COPY makes a copy constructor private and deleted). Hence a workaround.
|
|
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.
|
