Replacement for KDateTime

[John Layt]

On 4 August 2015 at 09:11, Thomas Lübking <thomas.luebking at gmail.com> wrote:
> On Montag, 3. August 2015 23:17:04 CEST, John Layt wrote:
>
>> Not nonsense, exactly my long-term plan to get Gtk and other apps to
>> use the right Plasma locale settings when running under Plasma. It
>> 'just' requires the kcm to learn how to write and compile a POSIX
>> locale file.
>
> That actually doesn't seem to be a really big deal - one would keep a set of
> adjustments and merge them into a copy of the base-de-toujours from
> /usr/share/i18n/locales/

You would need code to decompile and parse the source file, then code
to cleanly change the required values, then code to write it out in
the format the compiler wants. All achievable, the command line tools
may well support it, but still work that needs doing, and the last
step along the long path to locale nirvana once many more pressing
issues are solved. And when the underlying file gets updated you'll
need a mechanism to spot that and update the derived file too.

> One problem would be to update running processes (QLocale to track the
> locale file and emit some signal on changes)

This is one of the areas Qt doesn't do well, on Windows and Mac soon
as the underlying locale is change you get different results from
QLocale, leading to inconsistent looking UI and weird bugs. On Linux
it doesn't respond to changes at all until the app restarts, a more
consistent approach. The best approach would be to have a QEvent that
the app can catch and know to refresh everything when it is ready to
do so. Again, something on the plan but a longer term issue to solve,
as monitoring locale files or envvars or a registry for changes across
multiple platforms in Qt would take some work.

>> One problem is Qt completely ignores the contents of that file, and
>> indeed I'm not sure it would even manage to extract the correct locale
>> name even so you'd end up with some default.
>
> Humm?
>
> QLocale::name() should please return "KDE" in this case (where we may be a
> little smarter and name it en_KDE or de_KDE etc.)
>
> Where would that fail?

Well, QLocale wouldn't extract a valid language and country code from
it correctly to look up in it's internal locale database, so it would
fallback to using C locale instead. The name should also be standards
compliant so everything else would read it properly too, i.e. be valid
ISO codes etc, so something more like 'en_GB_kde'. And even once
around the name problems, QLocale would still be using its internal
data based on CLDR and not the override data held in the locale file
we point to. Nor do we want to use the data in the POSIX file as it
has too many shortcomings and lacks features and simply uses a
different set of format codes to CLDR. That POSIX file can only ever
really be used to tell non-Qt POSIX locale using apps what settings to
use under Plasma (i.e. Gtk/glibc stuff). If we're going to use a
locale file for Qt internally we'd be better looking to load the CLDR
json format instead. Indeed, it's an option I had been thinking of to
replace Qt's custom locale feature once we stop shipping our internal
CLDR data, or to allow embedded platforms to choose what supported
locales to ship, but there are issues there and I'm not sure it's
something Thiago would buy into.

John.