Re: [Development] QLocale work
On Tuesday, 24 de January de 2012 11.59.26, lars.kn...@nokia.com wrote: QTextStream should always stream in the C locale if the base is not decimal. 0x123.456,7 ftw or ftl? :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On 1/23/12 10:42 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On Monday, 23 de January de 2012 21.21.13, John Layt wrote: On Wednesday 18 Jan 2012 00:47:31 you wrote: * If we can port the QLocalePrivate number routines to call ICU instead of their current implementations, the rest of Qt will just work, Small wrinkle just turned up here, ICU only does parse/format for base 10 numbers and not for binary, octal or hex, which is technically correct as they are not localised formats, but it's a pain none-the-less. Because QLocale, QByteArray, QString and QTextStream offers the base option in the public API, we will need to keep the existing code to do it. If the requested parse/format is for base 10 then we'll pass it to ICU, otherwise we'll use the current code. We will just need to document the behaviour that other bases will always use the standard digits and not the local one. You mean QLocale and QTextStream. I am very tempted to simply break this. localized binary numbers simply don't make any sense. Cheers, Lars QByteArray and QString do not need ICU since they are locale-independent. Parse LC_ALL=C in them only. It's also a good idea to keep that code for when QT_NO_LOCALE is in effect. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ 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] QLocale work
On Wednesday 18 Jan 2012 13:21:24 lars.kn...@nokia.com wrote: On 1/18/12 12:35 PM, ext Thiago Macieira thiago.macie...@intel.com On Wednesday, 18 de January de 2012 00.47.31, John Layt wrote: 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. Yep, it's marked as API needing to change in Qt5, I just need to change the code that calls it in QTextStream and QSpinBox first. I suspect QSpinBox doesn't really need the low level parse access and can use QLocale directly, but QTextStream will probably still need its own parser. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On 1/19/12 4:15 AM, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday, 18 de January de 2012 21.24.36, Shaw Andy wrote: For what it is worth I also agree that it should be changed, having recently having to deal with the QDoubleValidator problem when it came to this became a right pain so making it only use the C locale unless explicitly told otherwise would be fine by me Note we're suggesting that UI components and widgets should default to the system locale, not the C locale. But they should have a setLocale for changing if necessary. Either way, as long as it's explicitly one and not checking the other I don't mind, it's when it was trying to accomodate the both that it got confusing to me :) Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Wednesday, January 18, 2012 00:42:26 John Layt wrote: Splitting up some related issues into separate emails to make it easier for people to address. Which ICU version to use? The latest ICU version is 4.8. See See http://site.icu-project.org/download for detailed release notes. OS X 10.6 shipped with ICU 4.0. Any idea what OSX 10.7 has? The earliest versios of major distro's to ship at least 4.0 are: * openSuse 11.1 shipped Dec 2008 with ICU 4.0 * Fedora 10 shipped Nov 2008 with ICU 4.0 * Ubuntu Lucid LTS shipped Apr 2010 with ICU 4.2 Not really relevant imo. Why use bleeding edge Qt with an old distro. Look to the future and what the latest has IMO. Ubuntu 12.04 has ICU 4.8: http://packages.ubuntu.com/precise/libicu-dev * Debian Squeeze shipped Oct 2011 with ICU 4.4 Harmattan shipped with ICU 4.4, and Android 1.6 possibly used ICU 4.2. Windows doesn't ship ICU so we get to choose. So ICU 4.0 seems the minimum version to target, although we lose some nice API and features as a result. What is lost that is relevant and when was it introduced? If relevant stuff is in a later (already released) version, I see no reason not to use it. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On 1/18/12 1:40 AM, ext John Layt jl...@kde.org wrote: 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. I'd say we should make QSystemLocale private for now. There's few reasons for it to be public and it might lead to BC problems further down the road. If it's private, we at least have full freedom to evolve the code base as needed. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On 1/18/12 1:42 AM, ext John Layt jl...@kde.org wrote: Splitting up some related issues into separate emails to make it easier for people to address. Which ICU version to use? The latest ICU version is 4.8. See See http://site.icu-project.org/download for detailed release notes. OS X 10.6 shipped with ICU 4.0. The earliest versios of major distro's to ship at least 4.0 are: * openSuse 11.1 shipped Dec 2008 with ICU 4.0 * Fedora 10 shipped Nov 2008 with ICU 4.0 * Ubuntu Lucid LTS shipped Apr 2010 with ICU 4.2 * Debian Squeeze shipped Oct 2011 with ICU 4.4 Harmattan shipped with ICU 4.4, and Android 1.6 possibly used ICU 4.2. Windows doesn't ship ICU so we get to choose. So ICU 4.0 seems the minimum version to target, although we lose some nice API and features as a result. ICU 4.0 implements Unicode 5.1 and CLDR 1.6. 4.0 is certainly a minimum version. Do you know which ICU versions did the upgrade to 5.2 and 6.0? Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
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
Re: [Development] QLocale work
On 1/18/12 2:21 PM, lars.kn...@nokia.com lars.kn...@nokia.com wrote: 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. For what it is worth I also agree that it should be changed, having recently having to deal with the QDoubleValidator problem when it came to this became a right pain so making it only use the C locale unless explicitly told otherwise would be fine by me :) Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Wednesday, 18 de January de 2012 21.24.36, Shaw Andy wrote: For what it is worth I also agree that it should be changed, having recently having to deal with the QDoubleValidator problem when it came to this became a right pain so making it only use the C locale unless explicitly told otherwise would be fine by me Note we're suggesting that UI components and widgets should default to the system locale, not the C locale. But they should have a setLocale for changing if necessary. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Wednesday, 18 de January de 2012 21.24.36, Shaw Andy wrote: For what it is worth I also agree that it should be changed, having recently having to deal with the QDoubleValidator problem when it came to this became a right pain so making it only use the C locale unless explicitly told otherwise would be fine by me Note we're suggesting that UI components and widgets should default to the system locale, not the C locale. But they should have a setLocale for changing if necessary. Should have? They already do http://developer.qt.nokia.com/doc/qt-4.8/qvalidator.html#setLocale, from the sounds of things it's just the fallback to the C locale that needs to go away. It's not exposed in QML though, I should probably do something about that. https://bugreports.qt.nokia.com/browse/QTBUG-23713 Andrew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
Splitting up some related issues into separate emails to make it easier for people to address. Which ICU version to use? The latest ICU version is 4.8. See See http://site.icu-project.org/download for detailed release notes. OS X 10.6 shipped with ICU 4.0. The earliest versios of major distro's to ship at least 4.0 are: * openSuse 11.1 shipped Dec 2008 with ICU 4.0 * Fedora 10 shipped Nov 2008 with ICU 4.0 * Ubuntu Lucid LTS shipped Apr 2010 with ICU 4.2 * Debian Squeeze shipped Oct 2011 with ICU 4.4 Harmattan shipped with ICU 4.4, and Android 1.6 possibly used ICU 4.2. Windows doesn't ship ICU so we get to choose. So ICU 4.0 seems the minimum version to target, although we lose some nice API and features as a result. ICU 4.0 implements Unicode 5.1 and CLDR 1.6. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Sunday 15 Jan 2012 22:53:31 Thiago Macieira wrote: On Sunday, 15 de January de 2012 23.09.35, John Layt wrote: * A QCldrLocale is not really needed for Qt purposes, it's only needed for anyone who wants to know what individual settings are, like KDE What would this class provide that the regular QLocale wouldn't? In the Locale KCM we need to know what each individual setting is so the user can change them. QLocale doesn't provide that, it's mostly just to/from routines with a few necessary settings like decimal point exposed mainly for other Qt classes like QString to use, and it really shouldn't be any more. The KCM could probably get what it needs by using QSystemLocale and directly querying ICU when QSystemLocale returns a null. Or we could change or remove the feature, but that's a flamewar for another list John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Sunday 15 Jan 2012 19:04:09 John Layt wrote: I think I'm favouring the second option as being cleaner and easier to implement in phases. After reading more of the ICU number API and trying some things out, I now think sticking closer to the current model will actually match the ICU API better and require less code albeit in one big bang. * QLocalePrivate holds instances of the ICU Locale, NumberFormat, DateFormat etc classes. QLocale methods call these objects directly to obtain format codes and perform format/parse without any call to QSystemLocale. * For Named locales, i.e. app creates QLocale instance for en_GB: QLocalePrivate is created, ICU Locale and format classes initialised. All QLocale calls will thus use only the CLDR default settings for the named locale. * For System locale, i.e. app creates default QLocale instance: QLocalePrivate created as per Named locales, but then calls QSystemLocale to obtain all the settings which are used to set the ICU NumberFormat and DateFormat default values. All QLocale calls will thus pickup the system settings. * A QCldrLocale is not really needed for Qt purposes, it's only needed for anyone who wants to know what individual settings are, like KDE. Note the ICU Format class instances may have delayed initialisation for efficiency, i.e. only when toString() is called for the first time. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Sunday, 15 de January de 2012 23.09.35, John Layt wrote: * A QCldrLocale is not really needed for Qt purposes, it's only needed for anyone who wants to know what individual settings are, like KDE What would this class provide that the regular QLocale wouldn't? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
