[Development] QLocale changes
jlayt at kde.org
Sun Oct 23 01:35:06 CEST 2011
Following on from my QDateTime changes to QLocale, there's a few other areas I
want to look into.
1) The following methods currently return QChar and as noted in the code need
to change to QString:
// ### Qt 5: We need to return QString from these function since
// unicode data contains several characters for these fields.
QChar decimalPoint() const;
QChar groupSeparator() const;
QChar percent() const;
QChar zeroDigit() const;
QChar negativeSign() const;
QChar positiveSign() const;
QChar exponential() const;
I've started on this, but run into the problem that these methods are used in
the number parsers which operate a QChar at a time. I would have to modify or
rewrite the parsers which is no small task, but the api change needs to be
done for 5.0. An interim step might be to change the api to QString now but
still only return the current 1 char values until the parsers can be adapted.
2) While doing (1), I could also add support for the System/CLDR values for
NAN, Infinity and Per Mille which are currently hard-coded.
2) Local Week Number systems, i.e US weeks
3) Numbering Systems (aka Digit Sets in KDE)
4) Change MeasurementSystem to use the supplemental CLDR data
5) Change default country for language to use the CLDR LanguageMatching data
6) Clean up QSystemLocale platform implementations to have more consistent
style, more complete support
Of these only 1) really needs to happen for 5.0.
Now for the KDE wishlist.
For KDE Frameworks 5 we want to switch to using QLocale, and QLocale now meets
our requirements except for the key ability for our users to modify individual
locale settings. While we can write a custom QSystemLocale to load the KDE
settings, there is no way to query all the current settings to show them to
the user in System Settings.
At QtCS I briefly discussed this with Denis and also QSystemLocale which
neither of us are too happy with. Denis indicated he was open to a different
approach for QSystemLocale and KDE settings so long as QLocale itself was kept
clean and simple for apps, i.e. no getters or setters for all the settings.
Currently we have QLocale which is mostly formatters/parsers with a few
methods to return certain settings, but many settings are not exposed. We
then have QSystemLocale which returns what the current host system settings
are where supported. QLocale first queries QSystemLocale for settings and if
none is returned then falls back to the CLDR settings. If not using the
default system locale, or support is disabled, then QSystemLocale is not
queried and the CLDR values are always used
The problem with QSystemLocale is it only tells you what the system locale
setting for something is, and only if that setting is supported, but not what
the CLDR fallback value is, which means KDE will be unable to query for the
values it wants.
I see two possible solutions:
1) Have QSystemLocale return the CLDR setting if it doesn't find or support
the system setting, or have a QSystemLocale just for CLDR.
2) Have a new QLocaleSettings class that returns either the system or CLDR
value as appopriate.
The big problem with 1) is that QSystemLocale is an optional feature so moving
all the CLDR look-up code there would break things, and I wouldn't want to
duplicate code either. Also it's not a nice api.
Option 2) would probably look like this:
* QLocale is the app facing api providing just those methods an average app
needs to use, i.e. mostly just formatters and parsers like toString() and
toInt() and not the format settings like decimalPoint(). It also keeps the
locale name/code parts, i.e. Language, Country, etc.
* QLocaleSettings is the platform facing api for those few people who need it
(i.e. KDE System Settings module, some specialised apps). This provides
direct api access to each setting like decimalPoint(). All the CLDR lookup
code gets moved here, and a method first looks up the QSystemLocale value if
enabled before defaulting to the CLDR value if needed. QLocale calls these
methods when it needs to find out what setting to use. QLocale also provides
a method to access the current QLocaleSettings it is using. Effectively it's
QLocale with the parser/fomatters removed and a new setitngs api added.
* QSystemLocale remains the same, using the virtual query() method and enum to
return the system setting, just extended over time with more settings.
The down side here is it adds a slightly unnecessary layer to everything.
More information about the Development