use QSettings::IniFormat everywhere

Review Request #129511 - Created Nov. 20, 2016 and updated

René J.V. Bertin
kate, kde-mac

A while back already there was a consensus on the frameworks-devel ML (backed by a few related RRs) that it was best to standardise on the QSettings::IniFormat to reduce the number of unnecessary platform differences, and to avoid storing settings in the registry on MS Windows.

I've been running KTextEditor with this patch for almost a year; somehow I forgot to submit it for review until now.

Tested since December 2015 on OS X 10.9.5 .

René J.V. Bertin
Review request changed

Change Summary:

dhaumann: Added Kåre


Dominik Haumann

What's unclear from this review request is what bug does it address?
If there was such a discussion on the mailing list, is there a link to it?

  1. Yeah, I imagine that it comes a bit out of the blue, about a year after this was discussed for other frameworks. Evidently I didn't keep references, but I should be able to find traces of the other RRs or else hopefully a commit or two.

    This doesn't address a bug in the strict sense. It addresses an omission which lets Qt use whatever default format it decided to use for a given platform. This means that documentation cannot describe a single, standard format where describing the content and layout of settings files is justified. It also means that settings are stored in the Windows Registry on MS Windows (unless Qt decides to change that), and possibly in binary plists (for which Apple no longer provides a standalone editor) on Mac.

    I'd think that using the Ini format everywhere also means that code manipulating settings files is more guaranteed to work as intended everywhere if it works on Linux where that format is "native".

Kåre Särs
I think that the decision to go for "ini-format-always" is up to the Sonnet guys, and then we have to adapt here accordingly. We just read the global setting here and it has to be the same as Sonnet is using otherwise we only get the default value. 

The settings handling in Sonnet is not optimal. The applications can not have their own private Sonnet settings it is always global :(

At one point I was planning to create a patch to expose the Sonnet setting object so that an application could set it's own private settings, but I never came around to doing it...
  1. This point already came up in the related Sonnet RR (

    I'm not having much luck until now finding references to the discussion on the ML or to RRs (but one can only search on title here, correct?)

  2. A migrating option could be to use QSettings::allKeys() to see if the "ini settings" contains any data and if not read/write the platform standard version on windows and mac. Removing the "old" setting is probably not good when the setting is global... it could have a settings clearing effect on older apps :)
  3. Eh? The proposition was not to use the platform standard version (QSettings::NativeFormat). But yes, in order to do things really properly one would need some form of migration (import using the old format, import using the IniFormat, write as IniFormat).

  4. Yes, only if the new default IniFormat is _empty_, would we check the NativeFormat. And use IniFormat after that.
  5. Fine with me, but that does assume that people don't run applications built against the old and the new format, doesn't it?

    FWIW, I notice that KWallet5 migrates my KDE4 wallet each time the latter has changed, which happens on a regular basis as I'm still using a KDE4 desktop.

    Anyway, this is a lesser concern here, an the per-application aspect could be as well. It is very likely that applications do not share the same ConfigLocation and/or DataLocation paths on systems where they are built to ship each with their own copy of all required frameworks.