Hi, Just to add to the background (and seeing as I'm the primary culprit in the death of KLocale and the slow pace of improvements to QLocale), there's 2 very big reasons for removing it (and the consequent loss of the customization feature): 1) It was very big and a maintenance burden, especially when Qt provides good-enough facilities for most purposes. The size stopped people using KDE libraries and reduced the number of potential KDE apps, and adding new features like proper collation and spell-out formatting would have taken a lot of duplicated work. 2) It was a walled garden, only KDE apps used the settings, all other apps ignored them, and KDE apps running on other desktops/platforms ignored their host settings, leaving an inconsistent user experience.
Just setting the standard POSIX codes has one very big advantage in being universal: all apps running under Plasma will respect them, rather than just KDE apps. If we implement a Qt-only solution then any POSIX/glibc/Java/Firefox/Chrome/etc apps will look out-of-place again, as they did under KDE4. Any solution needs to apply to everything (even if not everything is implemented at once). We do want the configurability back, I use it myself, but there's a series of technical steps we need to achieve first. The first is removing Qt's own locale system which has the same size/maintenance problems and has hard-coded locale data that cannot be changed, as well as being short on some features. I've written 3 different solutions so far over the last 2 years and none have been accepted. We do now have a fourth design that has come out of these efforts, and I have some code towards it, but I estimate it as a 6 month full-time effort to get it implemented, tested and integrated, as it is nothing less than a complete rewrite of all of QLocale for every platform Qt supports without breaking any previous behaviour or api. That is time I don't have to give right now, and no-one in the Qt world seems interested in paying for it in spite of many people wanting it (just like printing really). The design is basically to wrap the host services on each platform in a common api, with ICU as the chosen backend on Linux due to POSIX/glibc localization being totally useless. Unfortunately that means we end up catering for some lowest common denominator feature set, in this case Windows XP. If we ignore XP (and we will) then it's better but still not what we really want, and the current debate is whether we have an advanced api in QtCore that degrades gracefully on Windows, or if the advanced features go in a new QtLocale add-on module. Even once this full rewrite of QLocale is completed, that still doesn't give us the ability to edit individual settings on Linux (only Win and Mac), but it does set the precedent that QLocale should respect the users override settings and so make it acceptable to add some 'hacks' into Qt on Linux to make it work. For Qt the mechanism will probably be a small json file that stores the custom overrides that QLocale loads and then applies as overrides when calling in to ICU. But even once Qt reads and uses our custom settings, that still doesn't apply those settings to POSIX / glibc / gtk apps, we need an extra step there as well. There is a hack we could use, which is that the System Settings module could save a POSIX format locale file with the custom settings and set the LC_* envvar to point directly to the file, but that would require all toolkits to correctly implement the POSIX standard and I'm not convinced they do. Alternatively we could ask the user for the root password and install the locale file globally, but I'm not keen on that. It also doesn't solve things for apps that use ICU directly, like Chrome, where we have no possible solution. All that is besides the point with the System Settings module. We did say at the time that a drop-down with 200+ entries was probably not the best solution, but it was an interim implementation for 5.0. I'm sure with a little thought we can come up with a better way of managing such long lists, for example with a pop-up selector which includes filters by language or region, or something like that. Perhaps for metric/imperial we could be a little smarter and use the users chosen language or default locale to "guess" at a suitable locale match to use. For date/time format overrides, well that I'm afraid belongs in individual apps and plasmoids for now. John. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel