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 <[email protected]> wrote: >>> On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote: >>>> Em 10/10/2014 06:18, "Oswald Buddenhagen" < >>>> >>>> [email protected]> 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. > > Bye
We'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. André _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
