<div dir="ltr">Hey John,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 23, 2014 at 8:10 PM, John Layt <span dir="ltr"><<a href="mailto:jlayt@kde.org" target="_blank">jlayt@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
With the countdown to Plasma Next underway, I thought I'd better outline what<br>
needs to be done for locale settings, in particular the KCM, in case I don't<br>
find the time to do it.<br></blockquote><div><br></div><div>Thanks for that ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In KF5 we have switched to QLocale to remove the heavy dependency for KF5<br>
users and to better integrate with Qt apps and the host workspace. I've been<br>
working on bringing QLocale up to scratch, but it doesn't yet have the ability<br>
to load and use the custom KDE settings when running under Plasma Next, it<br>
will only use the standard POSIX envvars. This means that any changes made in<br>
the existing Locale KCM will be applied to KDE4 apps only, not KF5 apps that<br>
have removed the kde4support version of KLocale. We need to decide the best<br>
way to deal with this.<br></blockquote><div><br></div><div>Any ETA on the QLocale changes? Any particular plans with which we can help? I'd be happy to help out there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What we can do in Plasma Next is allow users to separately choose which locale<br>
code to apply for each of the standard unix envars (LC_ALL, LC_NUMERIC,<br>
LC_TIME, LC_MONETARY, LC_MESSAGES, LC_MEASUREMENT, LANG), and have these apply<br>
to *all* apps running under Plasma Next by having kdeinit set them at start-<br>
up. But how do we present that in a usable way in a KCM, and what do we do<br>
with the KDE4 settings and KCM?<br></blockquote><div><br></div><div>Some sort of temporary/transient KCM comes to mind...we could simply list the locale items ("Numeric system", "Time", "Money formatting"...) and combobox next to it with available locales, presented as countries ("Czech Republic", "Germany", "USA"...). It would be a bit ugly tho, but it would serve its purpose. Or have no KCM at all...I imagine the percentage of people setting different locales for each thing will be quite minimal...plus we can advertise that this will come back later (whenever QLocale is ready).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For KDE4 apps running under Plasma Next, I wonder if it will be too confusing<br>
having them using different locale settings than the KF5 apps? Perhaps on<br>
migrating from KDE4 to Plasma Next we delete any old user locale settings in<br>
kdeglobals and as a consequence the apps will use the same settings as all<br>
other apps under Plasma Next? If we do keep the old settings, then we will<br>
probably also need to keep the old KCM available.<br></blockquote><div><br></div><div>I'd be all for that, except that if people will have two sessions on their PCs, one for KDE4 and the other for Next, try out Next one time and this will nuke their KDE4 session settings, I imagine this will make them unhappy. And I think this will be quite common use case from the beginning as people will want to try things out. We could put a warning there, but that might scare some people off = less testing. Can we just override the KDE4 kdeglobals from Next? We could simply change the path or something and then the KDE4 apps won't be reading the KDE4 session kdeglobals file.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the new Locale KCM we will need to remove the separate Numbers, Money,<br>
Calendar, Date & Time and Other tabs for now. I'd suggest we no longer refer<br>
to the "Languages" tab but call it "Translations" instead, as that is what<br>
they really are, it configures how KLocalizedString works. Referring to them<br>
as Languages has created a lot of confusion, as has the current gui, but I'm<br>
not sure how to make it better. I'd also suggest changing the "Country" tab<br>
to "Formats", with a series of combo boxes to select the "Number Format",<br>
"Money Format", etc. We may be able to merge the Formats and Translations<br>
tabs into one layout but I suspect that will be too crowded, so instead<br>
perhaps we should have them as separate KCMs so they appear listed separately<br>
in the System Settings Locale group and sidebar as Formats, Translations, and<br>
Spell-Checker.<br></blockquote><div><br></div><div>Sounds good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One question is when these changes to the envvars will get applied, and the<br>
action required to apply them to the apps. I believe Gnome forces you to log<br>
out and in again before the new envvars are applied. In KDE4 you could simply<br>
restart individual apps, but to update Plasma itself you had to log out and<br>
in. Do we update the envars as soon as the KCM changes are saved, which would<br>
allow apps to simply be restarted, or would that be considered dangerous for<br>
running apps that assume the envvars won't change, e.g. would something like<br>
glibc immediately pick up the change and return inconsistent results?<br></blockquote><div><br></div><div>I think restarting Plasma while running would be easy. As to if it should be considered dangerous, I'm not educated enough to answer that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess another obvious question is where to save the envvar settings, I guess<br>
kdeglobals still? Or somewhere new?<br></blockquote><div><br></div><div>Not sure about this either...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Longer term we will need to restore the ability to edit the individual<br>
settings and I have a roadmap for that, but I'm expecting some negative user<br>
feedback in the meantime :-)<br></blockquote><div><br></div><div>Will there be QLocale/QML Locale support for that too? That'd be great ;)</div><div><br></div></div><div>Cheers</div>-- <br><div><span style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></div>
</div></div></div>