QSettings and "folders".
-
Technically, we could all live in a flat world. I can live with that if I'm forced to.
MY application will have a LOT of properties to be persisted, a lot of lists that need to be persisted and having dozens of flat list of 100 items on a level that already has hundreds of configuration elements is hard to maintain if you come from a support/debugging standpoint. I'd much rather use 'folders' on the pFile.
A list of one item where one item has 4 properties generates 5 pfile rows.... i may have thousands of those rows. I'd much rather categorize them and put them in folders.
-
OK I see. You could register your own format with QSettings (see the docs for "QSettings::registerFormat()":http://doc.qt.nokia.com/latest/qsettings.html#registerFormat. I have never tried this so I do not know how flexible it is.
I still dream of a QSettings backend for LDAP...
-
Well, ZapB... Qt is an open source project, no? why don't we just extend it to support just what we need?
BTW: if my QList holds my own type of objects, any chance I can hand it down to be persisted as a single object? or maybe convert it to ome kind of character stream and then convert that to HEX for storage? that way an array will always have one row/value. On the other hand, is there limit on the space a value can occupy?
-
Oh I know I could add support. The problem is lack of time.
You could derive a class from QList<MyType>, declare it to the metatype system via Q_DECLARE_METATYPE, and provide overloaded operators for it. I have not looked into what QSettings does to write out the qvariants that are passed into setValue() so I am not sure which operators you would need to overload. I'll try to take a look tomorrow.
-
For a custom type one must implement
@
QDataStream& operator<<(QDataStream &s, const MyType &t);
QDataStream& operator>>(QDataStream &s, MyType &t);
@Regarding the structure of the entries in the plist or registry, I personally do not care. As long as the performance is not decreasing, I see no big need in changing this. QSettings handles all this transparently. The current situation has at least the advantage, that the entries are all equally structured, regardless if we're talking about INI files, the Windows registry or Mac's plist files.
-
For me personally I don't really care about the storage format and whether it uses a lfat or hierarchical format as I do not tend to edit the settings by hand (well occasionally when deploying on embedded Liunx). So for me QSettings' abstraction works fine. I have not benchmarked it with many thousands of entries though.
-
I'm new to QT has there been any improvement with the QSettings that allows me to access hierarchical elements?
I am trying to read a setting from a plist that was created by a Java application. Java creates the hierarchical format by default.
Currently the way QT handles reads/writes plist settings in my opinion its not exactly cross platform. In windows if I write a value to the registry any application can read it. That is not the case with QT and the MAC.