Am 14.10.2014 um 18:44 schrieb Tomaz Canabrava: > On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff <milian.wo...@kdab.com > <mailto:milian.wo...@kdab.com>> wrote: > >> On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote: >>> QConfig and QConfigGroup *does not* support setting a default value >>> on the getter, I know that this is used in a lot of places but this >>> can cause inconsistencies: >>> >>> Main.cpp >>> >>> QConfig c; c.value("window-width", 800); >>> >>> MainWindow.cpp c.value("window-width", 1200); >>> >>> so we must create a better way for that. for now, I simply removed >>> the possibility for that, we can only do
I can imagine use cases where I'd like to have this flexibility. The best default value for an unspecified setting very much can depend on the context. >> Imo, this makes this API extremely inconvenient. Yes it's possible to >> do an error, but that is life. You should only add such >> error-prevention stuff into the high-level schema stuff, not into >> QConfig itself. I very much agree. > Since I wanted to add schema-validation on the low level stuff, this > wouldn't be an issue, 'value couldn't be read' would cause an assert. > but I can postpone this for later. I don't think it is wise to unconditionally crash programs for things that just during normal usage. With this string based API those settings schema and the actually accessing code are only losely coupled. So it will just happen that applications built for version A of the settings schema will access a configuration written with version B of the schema in mind. Because of program upgrades. Because the user has two versions of the same program installed. Because of human mistakes. Such situations must be handled gracefully: Users just don't like their programs crashing and maybe never starting again (without deleting various files). What's your graceful error handling plan for schema mismatches? Ciao, Mathias _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development