From: Chris C. <ca...@al...> - 2008-09-05 11:53:29
|
On 9/4/08, em...@us... <em...@us...> wrote: > KConfig * ==> QSettings * The mode of use for QSettings is a bit different from the old KConfig. Instead of looking up a global config object from the application, you are expected to just construct a new QSettings object each time you want to use one. For example, where we had before KConfig *config = kapp->config(); config->setGroup(someGroup); QString someValue = config->readEntry(someConfigKey); config->setGroup(someOtherGroup); QString someOtherValue = config->readEntry(someOtherConfigKey); we now want QSettings settings; settings.beginGroup(someGroup); QString someValue = settings.value(someConfigKey); settings.endGroup(someGroup); settings.beginGroup(someOtherGroup); QString someOtherValue = settings.value(someOtherConfigKey); settings.endGroup(someOtherGroup); The QSettings knows what settings file to use, because it queries the QApplication to find out. You don't ever have to tell it about that or worry about retaining state from one QSettings to another. This avoids problems with the same settings object being used in more than one thread at once. Note that it also requires changing lots of "->" to "." unless you are going to construct the settings object on the heap with new and delete. Similarly, it's no longer necessary (or desirable) to pass QSettings objects around between functions -- e.g. the configuration page constructors that used to take KConfig * as one of their arguments, should simply lose that argument rather than taking a QSettings instead. They should just make their own QSettings objects on the stack, locally within the functions in which they are needed. Chris |