> On Dec. 27, 2012, 10:33 a.m., Kevin Krammer wrote: > > I am a bit puzzled by the usage of QSettings for file I/O. > > > > My, rather limited, understanding of QSettings in Qt5 context is that is > > mostly the same as in Qt4 and Qt4's version is AFAIK neither capable of > > doing hierachical files nor immutable settings nor environment/tool-output > > dependent values. > > All of which KConfig can do and which could have been deployed (especially > > hierachy and immutability). > > > > Or maybe I am misunderstanding the purpose of this endeavour, i.e. is this > > just exploring options and not idended to be ever merged into KF5?
Right, QSettings doesn't do these things (well, it does hierarchical, but only two levels -- this is the most common use case, though). But this is about simple spell-checking... why would an administrator need immutable settings, or environment variables / tool output in config keys? This is typically user preferences. Any Qt-only library would do exactly this (use QSettings internally, waiting for a better solution in Qt). Yes, someone should really work on getting a better configuration framework into Qt (e.g. splitting out windows registry stuff out of QSettings, to make QSettings INI-only, add a KConfigGroup equivalent to QSettings, and make it support multiple levels of hierarchy via QStandardPaths). - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review24025 ----------------------------------------------------------- On Dec. 27, 2012, 12:52 a.m., Martin Tobias Holmedahl Sandsmark wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107791/ > ----------------------------------------------------------- > > (Updated Dec. 27, 2012, 12:52 a.m.) > > > Review request for KDE Frameworks, kdelibs and David Faure. > > > Description > ------- > > Ported everything away from KConfig to QSettings. > > I couldn't really find any users of the ::save function, so I think the > source incompatible change would be worth it. Alternatively we could add a > deprecated dummy function that takes in a KConfig object and just ignores it, > and uses QSettings. > > > Diffs > ----- > > kdeui/sonnet/configdialog.h 7c4993b > kdeui/sonnet/configdialog.cpp 625441b > kdeui/sonnet/configwidget.h 023b659 > kdeui/sonnet/configwidget.cpp 549d5af > kdeui/sonnet/highlighter.cpp 6cbb14c > kdeui/sonnet/tests/test_configdialog.cpp 4c4fd21 > kdeui/widgets/ktextedit.h d0c1c4d > kdeui/widgets/ktextedit.cpp 71d2a9f > staging/sonnet/src/core/backgroundchecker.h f0da3a3 > staging/sonnet/src/core/backgroundchecker.cpp dc05b94 > staging/sonnet/src/core/globals.cpp bf4f504 > staging/sonnet/src/core/loader.cpp 887aee5 > staging/sonnet/src/core/settings.cpp 59cb593 > staging/sonnet/src/core/settings_p.h e14bad7 > staging/sonnet/src/core/speller.h 37dd82f > staging/sonnet/src/core/speller.cpp f831f55 > > Diff: http://git.reviewboard.kde.org/r/107791/diff/ > > > Testing > ------- > > it builds. > > > Thanks, > > Martin Tobias Holmedahl Sandsmark > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
