On 4 August 2015 at 09:11, Thomas Lübking <thomas.luebk...@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.