On Tuesday, November 01, 2011 16:43:12 [email protected] 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" <[email protected]> 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 > >[email protected] > >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
