On 1/18/12 12:35 PM, "ext Thiago Macieira" <thiago.macie...@intel.com> wrote:
>On Wednesday, 18 de January de 2012 00.47.31, John Layt wrote: >> * QString will need a decision on the behaviour of toInt() / toLong() / >>etc >> using the Default Locale. > >They should use the C locale, not the Default (System) locale. Anything >in >QtCore, outside of QLocale, should default to the C locale unless >otherwise >explicitly requested. To deal with a specific locale, including the >system one, >the user needs to use QLocale or use explicit locale-relevant routines. >Higher-level classes, in end user-facing situations, like widgets and >QML, >however, should default to the system locale. > >We need to avoid the problem of printf / scanf that use different decimal >conventions depending on the user locale. That means the naive >implementation >will be unable to parse the data it generated under a different locale >settings. > >This is a slightly behaviour-incompatible change, but one I feel is >justified: >reading / parsing of data with comma as a decimal separator was already >broken, so we don't break it further; generating of data without >thousands >separators and with dots instead of commas for decimals is a minor >inconvenience. Yes, I'm all for changing this to use the C locale. Let's simply document it. > >> QLocale has friends which use QLocalePrivate methods and enums to >>perform >> number parse/format. >> >> * QString >> * QByteArray >> * QIntValidator >> * QDoubleValidatorPrivate >> * QTextStream >> * QTextStreamPrivate >> >> Other classes call public QLocale methods for number symbols like >> decimalPoint() and negativeSign() to use in their own custom >>char-at-a-time >> parse/format routines which will cause an issue as ICU / CLDR define >>these >> symbols as strings and not chars. I think we need to change the QLocale API here. IIRC there are a few locales where the decimal point is more than one char. The only safe thing is a QString, but we might want to also offer a lower level API that gives a const QChar * pointer and a length. > >QTextStream defaults to the C locale but it has a setLocale member for >changing that. QString and QByteArray can only do the C locale, except >where >the system one is explicitly requested ("%L1"). > >The validators (which are in QtGui) need a setLocale too, but unlike >QTextStream they should default to the system locale. > >Does anyone see a problem with different defaults? No, this is something that simply needs documentation. > >> QString - Well behaved, only uses the QLocalePrivate number methods and >> enums. Mostly only uses C Locale, but does use Default Locale first in >> toInt() / toLong() / etc methods, and in arg() methods if %L override >>used. > >See above. Only part that will use locale specific conversion is %L. > >> QByteArray - Very well behaved, only uses the QLocalePrivate number >>methods >> and enums, only uses C Locale. > >Good, looks done. > >> QIntValidator & QDoubleValidator - Very well behaved, only uses the >> QLocalePrivate number methods and enums. You can set/get locale to use, >> defaults to Default Locale but falls back to C Locale. > >Falling back is a bad idea, unless a Nokian can dig up from the old >history of >that codebase a compelling reason why it was done like that. Mainly trying to magically make things work. It's a bad idea. > >> QDateTimeParser is a private class used for basic date/time parsing in >> QLocale and QDateTime, but as a validating parser in QDateTimeEdit >>where it >> is very deeply embedded. It only uses the Default Locale unless you >> sub-class it. QLocale and QDateTime can easily port to use ICU >>(QDateTime >> probably using C Locale) but QDateTimeEdit still needs QDateTimeParser. >> It's not a great class or widget, so I'd suggest doing the minimal work >> required to port to ICU, rename it QDateTimeEditParser and move it to >> Widgets. > >Agreed. +1. Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development