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" <[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
