On Monday 16 Jan 2012 23:13:39 Thiago Macieira wrote: > I'd say that QLocale should return the information you need. If you need to > display that, why shouldn't QLocale provide that info? > > *Setting* the info is, however, out-of-scope for Qt.
When I was discussing it with Denis at QtCS he was fairly clear he didn't want to clutter up the QLocale api with lots of getX/getY/getZ api (he didn't like what was already there), but was happy for it to be in another class embedded in QLocale, which is why I've mentioned in the past a QLocaleSettings class, or doing something more with QSystemLocale to make it return all settings not just a limited subset of host settings. In fact, QSystemLocale is on my hit list, as both the implementation and its API seem to me ugly and awkward and a potential BIC problem. Currently the public base class has 2 virtual methods defined on it with no base implementation in the main file and no private d class. The main virtual query() method takes an enum and optional QVariant for the required setting and returns a QVariant holding the setting. Each host system file then implements the two virtual methods at base class level, i.e. not actually derived or virtual, but usually using a private d class or structure for the actual implementation. In the future as we add more features using CLDR, there's no guarantee the current API will stretch to fit and the virtual methods would normally make it fragile if they were actually being used that way. What I would prefer is to make the public QSystemLocale class a default implementation with non-virtual methods and a private d class that is virtual and has derived implementations for each platform. This seems safer and cleaner, and would also allow us to add a nicer more direct API, e.g. decimalPoint() instead of query(DecimalPoint). This base class then looks just like what a QLocaleSettings class should be, if the base d class were to return the CLDR settings. A system QLocale instance would have a pointer to the static global QSystemLocale instance to use, but a named QLocale instance would create it's own QSystemLocale without the system overrides. The QLocale parse/format methods would then just have a single code path querying the settings and passing them to ICU to use. That's one possible model anyway, there's still some thinking required on the finer details. John. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
