On Wednesday, 24 de August de 2011 00:14:48 Konstantin Ritt wrote: > maybe it is worth of breaking the source compatibility after all? > what if we'd split the QSettings (as it is right now) into two > independent classes? let's say QSystemSettings, which would use the > "native" storage, like registry on Windows, GConf on GNOME, ContextKit > on MeeGo, DefaultsSystem on Mac, etc., and QSettings - which would > provide only the basics (INI format support?) but would be so flexible > so that the user could implement (almost) any storage format support > for it via the backends (I'm actually thinking about the XML and, > sql[ite] format backends). I don't really care about those who uses > QSettings just to access the windows'es registry - so I didn't change > the class name (it's already perfect, imo) but if someone does, then > we probably may want to add (an obsoleted by-design?) QSystemSettings > backend for QSettings in order to make the transition period less > stressful for the user.
See the "System and global settings and platform plugins" thread for my take
on this.
I agree with you, except that I left unspecified how the platform plugin gets
the settings and I left unspecified what the replacement for application
settings should be.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
