[KDE/Mac] Country / Locale settings in non-KDE desktops/OS
johnlayt at googlemail.com
Thu Aug 27 22:26:36 CEST 2009
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
> 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
> * 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? :-)
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
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
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.
More information about the kde-mac