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
On 1/24/12 9:47 AM, "ext John Layt" wrote:
>
>On 24 Jan 2012 00:23, "John Layt" wrote:
>>
>> On Monday 23 Jan 2012 22:48:12 lars.kn...@nokia.com wrote:
>>
>> > I am very tempted to simply break this. localized binary numbers
>>simply
>> > don't make any sense.
>> >
>> > Cheers,
>> > Lars
>>
>> A
On 24 Jan 2012 00:23, "John Layt" wrote:
>
> On Monday 23 Jan 2012 22:48:12 lars.kn...@nokia.com wrote:
>
> > I am very tempted to simply break this. localized binary numbers simply
> > don't make any sense.
> >
> > Cheers,
> > Lars
>
> Agreed it makes no sense.
>
> My initial thought was just to
On Monday 23 Jan 2012 22:48:12 lars.kn...@nokia.com wrote:
> I am very tempted to simply break this. localized binary numbers simply
> don't make any sense.
>
> Cheers,
> Lars
Agreed it makes no sense.
My initial thought was just to move the code to say QString/QByteArray and
make it hard-code
On Monday 23 Jan 2012 19:42:57 Thiago Macieira wrote:
> You mean QLocale and QTextStream.
>
> QByteArray and QString do not need ICU since they are locale-independent.
> Parse LC_ALL=C in them only.
Yes, but the code is located in QLocalePrivate, and QSting/QByteArray create a
C QLocale to call
On 1/23/12 10:42 PM, "ext Thiago Macieira"
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
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 on
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
On Wednesday 18 Jan 2012 13:21:24 lars.kn...@nokia.com wrote:
> On 1/18/12 12:35 PM, "ext Thiago Macieira"
> >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 thei
On Wednesday 18 Jan 2012 09:35:02 Thiago Macieira 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.
On Wednesday 18 Jan 2012 13:13:04 you wrote:
> 4.0 is certainly a minimum version. Do you know which ICU versions did the
> upgrade to 5.2 and 6.0?
>
> Lars
Yep, ICU 4.4 got Unicode 5.2 and ICU 4.6 got Unicode 6.0.
OSX 10.7 shipped with ICU 4.6.
John.
__
On Wednesday 18 Jan 2012 12:17:48 you wrote:
> On Wednesday, January 18, 2012 00:42:26 John Layt wrote:
> Any idea what OSX 10.7 has?
OSX 10.7 shipped with ICU 4.6 which has Unicode 6.0
> > The earliest versios of major distro's to ship at least 4.0 are:
> > * openSuse 11.1 shipped Dec 2008 wit
On 1/19/12 4:15 AM, "Thiago Macieira" 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 makin
> 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
> > explicitl
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 oth
On 1/18/12 2:21 PM, "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.
On 1/18/12 12:35 PM, "ext Thiago Macieira"
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. Anyth
On 1/18/12 1:42 AM, "ext 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 shi
On 1/18/12 1:40 AM, "ext John Layt" 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
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.
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 lo
Looking at the knock-on effects code-wise to other classes in QtBase of
changing QLocale to use ICU. Behavioural changes are not covered.
tl;dr?
* If we can port the QLocalePrivate number routines to call ICU instead of
their current implementations, the rest of Qt will "just work", except
QT
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 distr
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
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 t
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.ma
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
b
Hi,
Apologies for an extended absence, life got rather busy. I've now pushed the
first of my QDate changes for review, but the QLocale stuff now needs more
focus as the next step.
Discussions back in November around QLocale resulted in a decision to move to
using ICU as the backend for all lo
28 matches
Mail list logo
