Country / Locale settings in non-KDE desktops/OS

[John Layt]

On Thursday 27 August 2009 18:48:08 Aaron J. Seigo wrote:
> as Ralf already pointed out, kdebase-runtime is as much a dependency for
>  any KDE application as kdelibs is. that's why it's called "runtime".

Right, that's the bit I was missing, explains things better.  So the 
difference is simply a more liberal policy to BIC/API stability as they are 
apps/random files that are not linked against?  I can't find any doco about 
this in techbase.

> sounds like KLocale needs to be able to back-end onto the different host
> systems, at least for defaults.

Yep, that's the idea, I remember it being mentioned pre-KDE4 but nothing 
happened.
 
> kcmshell is in runtime, so it's perfectly possible to run control panels.
> 
> having a separate control panel just for your KDE applications when running
>  in a different desktop shell is a bit silly. what probably should occur
>  is:
> 
> * the unique-to-KDE-apps settings panels show in the native settings app
> (whatever that is) by putting icons for them in it
> 
> * the not-unique-to-KDE-apps settings should be shared with the host system

Yep, that's my thinking too, why could I not have been as succinct? :-)

So:

1) KLocale when it finds it doesn't have a Country configured should try find 
the Country of the host shell and load that in preference to C.  
QLocale::system().country() could give this, albeit with some futzing around 
as it returns an enum not the ISO code?

2)  Have private backends for KLocale for Windows, OSX, and default, and 
possibly Gnome/whoever else.

3) Where the host shell has an equivalent locale setting the backend returns 
this instead of the kde setting (via QLocale::system()?), and the kcm either 
does not allow the user to set it or the kcm is not installed at all if no 
settings are applicable.

4) Where the host shell does not have an equivalent, the backend returns the 
kde setting which the user can configure in the kcm which should live in 
kdebase-runtime.

5) The individual kcm modules required integrate into the host shells settings 
program somehow, and only allow the setting of variables not provided by the 
host.

I'd say 1 is something that can be done pretty much straight away, and 2 to 4 
are something that can be migrated to over time as each option gets worked 
out, but 5 would obviously be  something for the Win/Mac teams to figure out 
when resources allow.  So long as the defaults are reasonable the inability to 
configure them is less serious.

John.