Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 8:31 AM, Milian Wolff wrote: > On Friday 10 October 2014 13:21:22 Oswald Buddenhagen wrote: > > On Fri, Oct 10, 2014 at 11:26:52AM +0200, Milian Wolff wrote: > > > On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote: > > > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: > > > > > may I ask why you don't simply copy KConfig? It's API design has > > > > > proven to be extremely versatile and efficient over the years. > > > > > > > > actually, it has proven horrible and is slated for a rewrite for a > > > > decade. the only thing it does right is what tomaz copied to his api. > > > > > > To my knowledge, only the internals are horrible and could easily be > > > improved, speed wise. > > > > the api is also horrible. it's full of inconsistencies. it has some > > specifics that make a clean multi-backend implementation not fully > > feasible. the c'tor flags for cascading and other features are rather > > error-prone. also, the duality of KConfig vs. KSharedConfig makes no > > sense. > > There are some dark corners in the API - that is correct. But you usually > don't have to care about that. The API that one uses normally is pretty > good > and definitely better than having to manually use references or such. > That's > what I have in mind when I talk about the good API of KConfig :) > > > on a different matter, what do we do about config change notifications? > > i tend to a separate class, say: > > > > QConfigWatcher::QConfigWatcher(const QConfigGroup &group); > > Q_SIGNAL changed(const QString &key); > > > > then we can postpone the actual design and implementation. > > Yeah, I like that idea, similar to what one can do via > KSettings::Dispatcher, > just nicer. > I tougth about having a changed() signal on the QConfig / QConfigGroup classes, is the QConfigWatcher a better approach? > > Bye > -- > Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin > > Milian Wolff | milian.wo...@kdab.com | Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote:
> On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
> > Em 10/10/2014 06:18, "Oswald Buddenhagen" <
> >
> > oswald.buddenha...@theqtcompany.com> escreveu:
> > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > > > may I ask why you don't simply copy KConfig? It's API design has
> > > > proven to be extremely versatile and efficient over the years.
> > >
> > > actually, it has proven horrible and is slated for a rewrite for a
> > > decade. the only thing it does right is what tomaz copied to his api.
> >
> > (still sleeping, só I will write better latter) I used kconfig and I
> > tougth it was terrible to use, that why I came to thiago and hélio Castro
> > asking if I could try a new one.
> >
> > I'll read the emails on this thread and change the code accordingly.
>
> Please double-check the KConfig API and copy more of its behavior. Some of
> that stuff was also mentioned by Thiago, Bo and Kai:
>
> QConfig("identifier_or_filename"); // this should also be the root group
>
> config.setValue("bla", 123); // would set a global config value, with
> multiple
> overloads or template functions
>
> QConfigGroup group = config.group("something"); // smart handle with
> reference
> semantics
> group.readValue("blub", /* default value */); // read value in group, also
> overloads and/or template function
>
> foreach (QConfigGroup subGroup, group.groups()) // or similar
>qDebug() << subGroup.name();
>
> I still think that KConfig, API-wise, is extremely convenient and haven't
> seen
> anything better so far. The internals and performance is a bit lacking, but
> usually not a problem and definitely not related to the API.
>
It's too error prone regarding typos.
// main.cpp
KConfig c;
KConfigGroup g = c.group("blah");
g.setValue("width", 10);
// otherfile
Kconfig c;
KConfigGroup g = c.group("blah");
g.value("widht"); // <- no error is issued, this is something that I wanna
have it fixed.
> --
> Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin
>
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 6:24 AM, Thiago Macieira wrote: > On Friday 10 October 2014 11:07:52 Milian Wolff wrote: > > may I ask why you don't simply copy KConfig? It's API design has proven > to > > be extremely versatile and efficient over the years. > > He is copying KConfig's API. That's why the main class is QConfigGroup, > like > KConfigGroup. > Actually, I'm not - this was a design decision because I didn't tougth of a better way to do it - I didn't even looked at the KConfig api, and the last time I used it was the KConfigXT , years ago. :) > > > So is there any reason > > for writing something from scratch, instead of picking KConfig and adding > > the JSON cache feature on-top? Maybe I'm just missing some context or > > previous discussion on that matter? > > Licensing. > > Unless you're able to contact all the contributors to KConfig and convince > them > to relicense under the CLA for inclusion into Qt, then you have the time to > clean it up. David wanted the same for KStandardDirs, but he ended up > rewriting from scratch for QStandardPaths and the result was much cleaner. > I'm > expecting the same here. > > > Note that KConfig uses a pluggable format in the background, so adding > > registry or plist support is possible. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 3:50 AM, wrote: > I once programmed a class hierarchy targeting the same features (and > much more). It consited of settings group objects and settings object > ordered in a tree hierarchy. That hierarchy was much more complex > (having templated settings, units, limits, flags, value checking, > attributes for GUI form generation etc.). Each of the groups and > settings shared a common interface base. > > One feature that was very useful was the fact that we could > display/edit the settings hierarchy using a QAbstractItemModel in a > QTreeView. > > Do you intend to support the latter with your classes? > Yes - the QConfig is actually a QAbstractTableModel already. > > -- > Regards, > Bernhard Lindner > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
Hey,
On Fri, Oct 10, 2014 at 3:37 AM, Bo Thorsen wrote:
> Hi Tomaz,
>
> Den 10-10-2014 kl. 00:43 skrev Tomaz Canabrava:
> > QConfig config;
> > QConfigGroup& root = config.root();
> > QConfigGroup& window = root.group("window");
>
> This looks a bit more complicated from the user point of view than it
> needs to be. But this might be because I don't know what the QConfig
> class does. If it's pretty much only a wrapper that holds the root and
> the file name, I would prefer that it's not exposed to the user.
>
> First possible way:
>
> QConfig config(optional filename);
>
Already works with filenames. :)
> config.setValue(...
> QConfigGroup window(config, "window");
>
Just changed to value semantics, got that out of the box. :)
> or
>
> QConfigGroup config(optional filename, optional QConfig)
>
> Thiago asked you not to use references. A design where you have an
> internally shared object that is the top config could work around this.
>
> But, as I said above, I'm not sure what your plans are for your QConfig
> class, and what the responsibilities of it are.
>
> Bo Thorsen,
> Director, Viking Software.
>
> --
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 7:25 AM, Ziller Eike wrote: > > On Oct 10, 2014, at 3:37 PM, Adam Light wrote: > > > On the flip side, our large Qt application runs on Mac and Windows and > we're intentionally using QSettings with INI format on both platforms for > consistency. Since the storage of settings is really an implementation > detail (users should hopefully never need to edit the settings files > themselves), it's easier for us if the settings are stored the same way on > all platforms. > > Qt Creator intentionally used ini format for “consistency” as well, but: > * Since the paths are different through the platforms (Windows XP vs > Windows vs Linux vs OS X), and have to be, there is not much consistency in > the end after all, and > * Uninstallation process involves manually removing settings and > application data, at least on OS X, and there are even uninstallation tools > out there which do it for you, if the application follows the platform > convention > > So there are IMO very good reasons why someone would want their > application to follow platform conventions for application settings. > Possibly with a way to opt-in or opt-out. > > Sure, I understand why a developer might want an application to be able to follow platform conventions. I'm just making the case that I think there are valid reasons to *not* follow platform conventions as well. Currently QSettings makes it relatively easy for the developer to decide. But if this new class is eventually going to replace QSettings, I feel that the option should remain for the developer to force the settings to be saved in a consistent way across platforms, not always using the platform convention. Otherwise it's a loss of functionality. Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Account problems with codereview.qt-project.org
Hello Everyone, I was told to look for help here. I have an jira account for bugreports.qt-project.org and now tried to push some code into codereview.qt-project.org. Log in goes ok, but when i try to register my email it gives me this error: "Identity in use by another account". Please help. Steps: 1 - log in codereview.qt-project.org 2 - codereview.qt-project.org/#/settings/contact 3 - click in 'Register new E-mail' 4 - Receive an e-mail and click the verification link 5 - gerrit gives me: "Identity in use by another account". Don't remeber register this e-mail in any other account. Please point directions. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Oct 10, 2014, at 3:37 PM, Adam Light wrote: >> On Fri, Oct 10, 2014 at 4:27 AM, Ziller Eike >> wrote: >> >> On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig >> wrote: >> >> >> >> >>> Mac people: do we need access to plist files? >> >> >> >> Plist is the format for application and other settings on OS X, and there >> >> are native tools for nicely editing these. Ini is highly alien on OS X. >> >> So, I’d answer yes. >> > >> > On the other hand, git uses the ini file format for the config files also >> > on OS X. >> >> git is a command line tool, and used by a very specific audience. >> >> > I see this as two separate use cases: >> > 1) Cross-platform API for managing application settings. >> >> We regularly have people which complain that Qt Creator application settings >> do not follow platform convention on OS X, because they do not find a qt >> creator plist in ~/Library/Preferences, or actually there is one that >> contains some settings coming from Qt (NSNavLastRootDirectory, >> PMPrintingExpandedState, some WebKit stuff, and a few more), but not the >> actual application settings. >> > > On the flip side, our large Qt application runs on Mac and Windows and we're > intentionally using QSettings with INI format on both platforms for > consistency. Since the storage of settings is really an implementation detail > (users should hopefully never need to edit the settings files themselves), > it's easier for us if the settings are stored the same way on all platforms. Qt Creator intentionally used ini format for “consistency” as well, but: * Since the paths are different through the platforms (Windows XP vs Windows vs Linux vs OS X), and have to be, there is not much consistency in the end after all, and * Uninstallation process involves manually removing settings and application data, at least on OS X, and there are even uninstallation tools out there which do it for you, if the application follows the platform convention So there are IMO very good reasons why someone would want their application to follow platform conventions for application settings. Possibly with a way to opt-in or opt-out. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 4:27 AM, Ziller Eike wrote: > > On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig > wrote: > > >> > >>> Mac people: do we need access to plist files? > >> > >> Plist is the format for application and other settings on OS X, and > there are native tools for nicely editing these. Ini is highly alien on OS > X. > >> So, I’d answer yes. > > > > On the other hand, git uses the ini file format for the config files > also on OS X. > > git is a command line tool, and used by a very specific audience. > > > I see this as two separate use cases: > > 1) Cross-platform API for managing application settings. > > We regularly have people which complain that Qt Creator application > settings do not follow platform convention on OS X, because they do not > find a qt creator plist in ~/Library/Preferences, or actually there is one > that contains some settings coming from Qt (NSNavLastRootDirectory, > PMPrintingExpandedState, some WebKit stuff, and a few more), but not > the actual application settings. > > On the flip side, our large Qt application runs on Mac and Windows and we're intentionally using QSettings with INI format on both platforms for consistency. Since the storage of settings is really an implementation detail (users should hopefully never need to edit the settings files themselves), it's easier for us if the settings are stored the same way on all platforms. Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Friday 10 October 2014 13:21:22 Oswald Buddenhagen wrote: > On Fri, Oct 10, 2014 at 11:26:52AM +0200, Milian Wolff wrote: > > On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote: > > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: > > > > may I ask why you don't simply copy KConfig? It's API design has > > > > proven to be extremely versatile and efficient over the years. > > > > > > actually, it has proven horrible and is slated for a rewrite for a > > > decade. the only thing it does right is what tomaz copied to his api. > > > > To my knowledge, only the internals are horrible and could easily be > > improved, speed wise. > > the api is also horrible. it's full of inconsistencies. it has some > specifics that make a clean multi-backend implementation not fully > feasible. the c'tor flags for cascading and other features are rather > error-prone. also, the duality of KConfig vs. KSharedConfig makes no > sense. There are some dark corners in the API - that is correct. But you usually don't have to care about that. The API that one uses normally is pretty good and definitely better than having to manually use references or such. That's what I have in mind when I talk about the good API of KConfig :) > on a different matter, what do we do about config change notifications? > i tend to a separate class, say: > > QConfigWatcher::QConfigWatcher(const QConfigGroup &group); > Q_SIGNAL changed(const QString &key); > > then we can postpone the actual design and implementation. Yeah, I like that idea, similar to what one can do via KSettings::Dispatcher, just nicer. Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig wrote: >> >>> Mac people: do we need access to plist files? >> >> Plist is the format for application and other settings on OS X, and there >> are native tools for nicely editing these. Ini is highly alien on OS X. >> So, I’d answer yes. > > On the other hand, git uses the ini file format for the config files also on > OS X. git is a command line tool, and used by a very specific audience. > I see this as two separate use cases: > 1) Cross-platform API for managing application settings. We regularly have people which complain that Qt Creator application settings do not follow platform convention on OS X, because they do not find a qt creator plist in ~/Library/Preferences, or actually there is one that contains some settings coming from Qt (NSNavLastRootDirectory, PMPrintingExpandedState, some WebKit stuff, and a few more), but not the actual application settings. > 2) API for reading native settings, following the conventions of the platform What kind of native settings are you thinking about here (on OS X)? > To what degree was QSettings successful in combining these? Focusing on > ini+json as supported formats will certainly simplify the implementation work. > > Morten > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 11:26:52AM +0200, Milian Wolff wrote: > On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote: > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: > > > may I ask why you don't simply copy KConfig? It's API design has > > > proven to be extremely versatile and efficient over the years. > > > > actually, it has proven horrible and is slated for a rewrite for a > > decade. the only thing it does right is what tomaz copied to his api. > > To my knowledge, only the internals are horrible and could easily be > improved, speed wise. > the api is also horrible. it's full of inconsistencies. it has some specifics that make a clean multi-backend implementation not fully feasible. the c'tor flags for cascading and other features are rather error-prone. also, the duality of KConfig vs. KSharedConfig makes no sense. on a different matter, what do we do about config change notifications? i tend to a separate class, say: QConfigWatcher::QConfigWatcher(const QConfigGroup &group); Q_SIGNAL changed(const QString &key); then we can postpone the actual design and implementation. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On 10-Oct-14 11:48, Morten Johan Sørvig wrote: > I see this as two separate use cases: > 1) Cross-platform API for managing application settings. > 2) API for reading native settings, following the conventions of the platform > > To what degree was QSettings successful in combining these? Focusing on > ini+json as supported formats will certainly simplify the implementation work. For the Windows registry, QSettings is quite convenient to use, though there's no real benefit of using the registry compared to ini files. But there are idosyncrasies of the Windows registry that are IMO out of scope for QSettings. See QTBUG-2894 for example. I think that QConfig should only cover use case 1, and native wrapper classes can handle case 2. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building Qt 5 in release mode with debug symbols
On Friday 10 October 2014 11:39:33 Milian Wolff wrote: > Hello all, > > once more I'm preparing a Qt 5 build for profiling purposes and wonder again > why there is no way to combine -release and -debug in Qt's configure > script. The only way to get a sane build for profiling Qt code itself that > I know of is hacking the mkspec and ensuring that -g is added even in > -release mode. > > Is there any reason for that? Could we improve this situation somehow to > make it simpler to get a Qt build with optimizations and debug symbols? > > Am I missing the recommended way to get this done? Ugh, apparently I'm out of the loop here. While looking at the mkspecs, I noticed the (to me) new *_RELEASE_WITH_DEBUGINFO qmake variables. That lead me in turn to try out the (still mac-only) -debug-and-release once more which prints the somewhat cryptic message that its not required anymore thanks to separate debug information. Reading the output of configure -help then finally gave me -force-debug-info, so I'm now trying this out. ./configure ... -release -force-debug-info Is that the recommended way to get this done? Thanks, sorry for the noise (probably) -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
> >> Mac people: do we need access to plist files? > > Plist is the format for application and other settings on OS X, and there are > native tools for nicely editing these. Ini is highly alien on OS X. > So, I’d answer yes. On the other hand, git uses the ini file format for the config files also on OS X. I see this as two separate use cases: 1) Cross-platform API for managing application settings. 2) API for reading native settings, following the conventions of the platform To what degree was QSettings successful in combining these? Focusing on ini+json as supported formats will certainly simplify the implementation work. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building Qt 5 in release mode with debug symbols
On Friday, October 10, 2014 11:39:33 Milian Wolff wrote: > Hello all, > > once more I'm preparing a Qt 5 build for profiling purposes and wonder again > why there is no way to combine -release and -debug in Qt's configure > script. The only way to get a sane build for profiling Qt code itself that > I know of is hacking the mkspec and ensuring that -g is added even in > -release mode. > > Is there any reason for that? Could we improve this situation somehow to > make it simpler to get a Qt build with optimizations and debug symbols? > > Am I missing the recommended way to get this done? Hi, -force-debug-info: Create symbol files for release builds. Should work no ? Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Building Qt 5 in release mode with debug symbols
Hello all, once more I'm preparing a Qt 5 build for profiling purposes and wonder again why there is no way to combine -release and -debug in Qt's configure script. The only way to get a sane build for profiling Qt code itself that I know of is hacking the mkspec and ensuring that -g is added even in -release mode. Is there any reason for that? Could we improve this situation somehow to make it simpler to get a Qt build with optimizations and debug symbols? Am I missing the recommended way to get this done? Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
> Em 10/10/2014 06:18, "Oswald Buddenhagen" <
>
> oswald.buddenha...@theqtcompany.com> escreveu:
> > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > > may I ask why you don't simply copy KConfig? It's API design has
> > > proven to be extremely versatile and efficient over the years.
> >
> > actually, it has proven horrible and is slated for a rewrite for a
> > decade. the only thing it does right is what tomaz copied to his api.
>
> (still sleeping, só I will write better latter) I used kconfig and I
> tougth it was terrible to use, that why I came to thiago and hélio Castro
> asking if I could try a new one.
>
> I'll read the emails on this thread and change the code accordingly.
Please double-check the KConfig API and copy more of its behavior. Some of
that stuff was also mentioned by Thiago, Bo and Kai:
QConfig("identifier_or_filename"); // this should also be the root group
config.setValue("bla", 123); // would set a global config value, with multiple
overloads or template functions
QConfigGroup group = config.group("something"); // smart handle with reference
semantics
group.readValue("blub", /* default value */); // read value in group, also
overloads and/or template function
foreach (QConfigGroup subGroup, group.groups()) // or similar
qDebug() << subGroup.name();
I still think that KConfig, API-wise, is extremely convenient and haven't seen
anything better so far. The internals and performance is a bit lacking, but
usually not a problem and definitely not related to the API.
--
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Louai Al-Khanji as approver
Thanks for the votes of confidence! -- Louai From: development-bounces+louai.al-khanji=theqtcompany@qt-project.org on behalf of Blasche Alexander Sent: Friday, October 10, 2014 11:17 AM To: development@qt-project.org Subject: Re: [Development] Nominating Louai Al-Khanji as approver Congratulations. The Approver rights have been set in Jira and Gerrit. -- Alex From: development-bounces+alexander.blasche=digia@qt-project.org on behalf of Friedemann Kleint Sent: Friday, September 19, 2014 10:31 To: development@qt-project.org Subject: [Development] Nominating Louai Al-Khanji as approver Hi, I'd like to nominate Louai Al-Khanji as approver in the Qt Project: https://codereview.qt-project.org/#/q/owner:louai.al-khanji,n,z https://codereview.qt-project.org/#/q/reviewer:louai.al-khanji,n,z He implemented the Windows Direct2D platform plugin (which works well beyond expectations) and has also done significant work in other areas (Qt3D, Wayland). Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote: > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: > > may I ask why you don't simply copy KConfig? It's API design has > > proven to be extremely versatile and efficient over the years. > > actually, it has proven horrible and is slated for a rewrite for a > decade. the only thing it does right is what tomaz copied to his api. To my knowledge, only the internals are horrible and could easily be improved, speed wise. But the licensing issue that Thiago raised is a valid one of course. -- Milian Wolff m...@milianw.de http://milianw.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Friday 10 October 2014 11:07:52 Milian Wolff wrote: > may I ask why you don't simply copy KConfig? It's API design has proven to > be extremely versatile and efficient over the years. He is copying KConfig's API. That's why the main class is QConfigGroup, like KConfigGroup. > So is there any reason > for writing something from scratch, instead of picking KConfig and adding > the JSON cache feature on-top? Maybe I'm just missing some context or > previous discussion on that matter? Licensing. Unless you're able to contact all the contributors to KConfig and convince them to relicense under the CLA for inclusion into Qt, then you have the time to clean it up. David wanted the same for KStandardDirs, but he ended up rewriting from scratch for QStandardPaths and the result was much cleaner. I'm expecting the same here. > Note that KConfig uses a pluggable format in the background, so adding > registry or plist support is possible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
Em 10/10/2014 06:18, "Oswald Buddenhagen" < oswald.buddenha...@theqtcompany.com> escreveu: > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: > > may I ask why you don't simply copy KConfig? It's API design has > > proven to be extremely versatile and efficient over the years. > > > actually, it has proven horrible and is slated for a rewrite for a > decade. the only thing it does right is what tomaz copied to his api. (still sleeping, só I will write better latter) I used kconfig and I tougth it was terrible to use, that why I came to thiago and hélio Castro asking if I could try a new one. I'll read the emails on this thread and change the code accordingly. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Friday 10 October 2014 06:47:39 Ziller Eike wrote: > I think it would not be good to create a new API for settings, and > simultaneously force us to keep the old API because the new API doesn’t > cover the old use cases. So, if Windows registry access should not be done > through the new settings API (which I can’t tell), we should have a > dedicated API for it at the same time the new settings API is introduced. Ossi was talking about moving the qtbase/tools/shared/windows/registry* class into QtCore. That would be the replacement. > > Mac people: do we need access to plist files? > > Plist is the format for application and other settings on OS X, and there > are native tools for nicely editing these. Ini is highly alien on OS X. So, > I’d answer yes. So you're saying that QConfig should read from and save to Plist files on Mac, instead of .ini files. Is that it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: > may I ask why you don't simply copy KConfig? It's API design has > proven to be extremely versatile and efficient over the years. > actually, it has proven horrible and is slated for a rewrite for a decade. the only thing it does right is what tomaz copied to his api. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Thursday 09 October 2014 19:43:08 Tomaz Canabrava wrote: > Please be kind, this is the first step to contributing to qt that I'm > trying. :) > > First, I'v implemented the rationale that thiago asked me to do on the > other thread: > > Settings format: .ini ( current settings uses native format, should I > implement that too or the reasoning here is 'be simple'? ) > > Cache format: binary json > > If the json cache was created before the .ini, it will recreate the cache. > > Internal format: I'v created a QConfigGroup / QConfig / QConfigCore set of > classes, that can be renamed if it better fits. > > Usage on code: Hey Tomaz, may I ask why you don't simply copy KConfig? It's API design has proven to be extremely versatile and efficient over the years. So is there any reason for writing something from scratch, instead of picking KConfig and adding the JSON cache feature on-top? Maybe I'm just missing some context or previous discussion on that matter? Note that KConfig uses a pluggable format in the background, so adding registry or plist support is possible. Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Louai Al-Khanji as approver
Congratulations. The Approver rights have been set in Jira and Gerrit. -- Alex From: development-bounces+alexander.blasche=digia@qt-project.org on behalf of Friedemann Kleint Sent: Friday, September 19, 2014 10:31 To: development@qt-project.org Subject: [Development] Nominating Louai Al-Khanji as approver Hi, I'd like to nominate Louai Al-Khanji as approver in the Qt Project: https://codereview.qt-project.org/#/q/owner:louai.al-khanji,n,z https://codereview.qt-project.org/#/q/reviewer:louai.al-khanji,n,z He implemented the Windows Direct2D platform plugin (which works well beyond expectations) and has also done significant work in other areas (Qt3D, Wayland). Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
