[Development] Notes of the QSetting session at DevDays meeting

[Andreas Hartmetz]

Hi all,

At the DevDays contributors day there was a meeting with interested
parties from QtDF and the (mostly KDE-related) community about a
replacement for the scheduled-to-be-removed QSettings. Before the
meeting I gathered that there is interest in using DConf as the backend,
so I prepared a list of points related to that.
During the meeting I edited the list of points, added answers and added
some new questions that came up.

Here is the list of points, slightly edited after the meeting, for
reading and further discussion:

QSettings:
- Group support: cd-like API = bad
- Suboptimal performance
- Somewhat wasteful storage format: the fully-qualified name including
  all parent groups of each entry is serialized for each entry.
- Limited cascading support (file of same name in some hardcoded path(s))
- Not conforming to desktop file standard

Replacement requirements:
- Should have "QSettingsGroup" like KConfigGroup - MUCH less error-prone
- Good performance (UTF-16 storage? DConf doesn't have that yet)
- (More) space-efficient storage format
- Full cascading config support (to support a full desktop environment)
- Platform storage backend support?
  Consider same backend on all platforms, then consider offering
  QWindowsRegistry (+ something for OSX) for native configuration support
  where applications need it for external reasons.
- What about DConf?
  - Needs translators to and from plaintext so the Unix text tools and
    editors can be used
  - How are the config files and / or cache files laid out and what do
    they contain? TODO
  - Can serialize / synchronize changes via a daemon (desired feature)
  - Binary UTF8-based encoding
  - Still need .desktop file access somehow -> TODO QDesktopFile
- How to watch and broadcast changes, if we want to support
  "apply immediately" in settings dialogs?
  - Efficiency (or good high-level API) questionable, just a gut feeling
    from working on similar stuff.
    I've looked at some DConf code after the meeting but couldn't figure
    out how the code worked (for shame).
    Would have to look harder and look at surrounding code, too.
  - What about transaction / sync support for atomic changesets?
    Example: in mail client, when changing hostname: hostname, username,
    and password should change either all or not at all.
- Would be very nice to have it good enough to replace KConfig, so for
  example kDebug could be moved to Inqlude without further dependencies.
- KConfig code reuse possible?
  No: QtCore code can't be LGPL, and too many authors for relicensing!
- Which module should it be in?
  QtCore, unless very complex, which it shouldn't be
- Environment & shell expression expansion & immutable flag (Kiosk)?
  Not sure: looks potentially ugly to support well, but would have to be
  done manually where it was used.

Cheers,
Andreas