On 13.10.2014 13:46, André Somers wrote:
Milian Wolff schreef op 11-10-2014 16:44:On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote:On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff <milian.wo...@kdab.com> wrote:On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:Em 10/10/2014 06:18, "Oswald Buddenhagen" <oswald.buddenha...@theqtcompany.com> escreveu:On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:may I ask why you don't simply copy KConfig? It's API design has proven to be extremely versatile and efficient over the years.actually, it has proven horrible and is slated for a rewrite for a decade. the only thing it does right is what tomaz copied to his api.(still sleeping, só I will write better latter) I used kconfig and I tougth it was terrible to use, that why I came to thiago and hélio Castro asking if I could try a new one. I'll read the emails on this thread and change the code accordingly.Please double-check the KConfig API and copy more of its behavior. Some of that stuff was also mentioned by Thiago, Bo and Kai: QConfig("identifier_or_filename"); // this should also be the root group config.setValue("bla", 123); // would set a global config value, with multiple overloads or template functions QConfigGroup group = config.group("something"); // smart handle with reference semantics group.readValue("blub", /* default value */); // read value in group, also overloads and/or template function foreach (QConfigGroup subGroup, group.groups()) // or similar qDebug() << subGroup.name(); I still think that KConfig, API-wise, is extremely convenient and haven't seen anything better so far. The internals and performance is a bit lacking, but usually not a problem and definitely not related to the API.It's too error prone regarding typos. // main.cpp KConfig c; KConfigGroup g = c.group("blah"); g.setValue("width", 10); // otherfile Kconfig c; KConfigGroup g = c.group("blah"); g.value("widht"); // <- no error is issued, this is something that I wanna have it fixed.How do you intend to fix it? Esp. when looking at what Rafael proposes? If you declare any other class to be used instead of a string, the user can still mix two variables up. I don't see what that has to do with KConfig/QConfig, really. ByeWe're moving away from using these keys directly at all. Instead, we only use a real, type safe interface anymore for settings. That is: every setting gets a real getter and setter in a Settings class. That class is responsible for storing and retreiving the setting from the backend (which, in our case, has several levels now). If needed, there is not only a getter and a setter, but also a corresponding changed signal, but that changed signal currently only works if the setting is changed from inside the application itself (good enough for us). Personally, I think that using string-based key-value pairs (whether the key has grouped semantics or not) and then manually casting the value to the needed everywhere you need it simply has no place in application code in all but the simplist applications. API's need to be type-safe if at all possible, and if not, the exposure to the non-type safe API should be kept to a minimum. Further more: default values need to be consistent. Allowing the application to access the backend from more than one place, also means having the specify the default value for settings in more than one place. That *will* lead to inconsistencies. In our case, that means that there is only one class where there is exposure to the non-type safe QVariant-based API of Qt, and that is the settings class itself. The rest of the application has no clue, nor needs to have any clue, on how the settings are stored: they are just using type-safe properties with clearly defined default values. I would like to see some (modular) kConfig XT-like settings specification that results in type save code within Qt though. Preferably with a nice editor-plugin inside Creator. Or, perhaps based on the Q_PROPERTIES or something similar allowing you to use a default getter/setter implementation for simple cases, and add your own for more complex ones. That would already save a lot of boilerplate code. I don't believe in auto-generating configuration dialogs, though a tree representation would be useful for advanced editing and developer settings.
+1, something like KConfigXT that auto-generates QObjects with appropriate getters, setters and Q_PROPERTIES would be very useful. Not just for type safety - also for exporting settings objects directly to the QML world, which otherwise is a lot of boilerplate code to write.
Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
