[Development] Notes of the QSetting session at DevDays meeting

[Andreas Hartmetz]

On Tuesday, November 01, 2011 16:43:12 cristiano.di-flora at nokia.com wrote:
> 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.

It was an unconference (no schedule in advance), so at best you could have 
known about there being an unconference.

> 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 was unaware of the existence of QtSystems and we didn't talk about it.

> 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 don't know the purpose of QtSystems, how it's supposed to be maintained, and 
in fact not even why exactly DConf is so interesting as a QSettings backend.
 
> I would be more than interested to hear your opinion as well as of all
> other people who are interested in this topic.
> 
I just ran the session because I wanted such a session to happen, not because 
I know very much about the topic. Anybody else?

> Cheers,
> -Cristiano
> 
> 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