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. _______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
