[Development] Notes of the QSetting session at DevDays meeting

[cristiano.di-flora at nokia.com]

Hi Andreas / all,


I have been at the DevDays in Munich, and unfortunately I was not aware
about this meeting...would have been nice and helpful to join the
discussion there.
I am reading your notes with the QtSystems "hat" and I see a lot of
potential synergy with the QtSystems' Qt Publish&Subscribe API.
Especially when considering the watch and broadcast ideas below, I
immediately think about the ValueSpace abstraction provided by
Publish&Subscribe.
Have you discussed the idea at all at the DevDays? Would it make sense to
plan to add a Dconf backend to P&S?
I have the feeling that you are more interested in adding new back-ends to
Publish&Subscribe, rather than in trying to turn QSettings into something
that will look very close to what the P&S API is about. Of course, since I
have not joined the discussion in person, my feeling is just based on your
notes ;)

I would be more than interested to hear your opinion as well as of all
other people who are interested in this topic.

Cheers,
-Cristiano

________________________________________
Cristiano di Flora, PhD

SW Architect / Technical lead,

Nokia - Qt Software development

Visiokatu 3
33720, Tampere (FINLAND)
________________________________________





On 11/1/11 2:35 AM, "ext Andreas Hartmetz" <ahartmetz at gmail.com> wrote:

>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
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development