----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4915/ -----------------------------------------------------------
Review request for kde-windows and kdelibs. Summary ------- Currently, if the user has not set a Country in System Settings, then KDE assumes C and uses the default settings for things like date formats. This is not very friendly, especially under Mac/Win where the user may not realise where/how to fix this. This change tries to detect what the host system locale Country is and use that to load the KDE format settings. For Mac/Win, this is an interim step by faking the correct settings, later changes will directly read the Mac/Win settings and translate them into KDE formats. What's changed: 1) Try to fix my stupidity in not knowing how virtuals work in constructors by flagging at which level the init needs to be called to ensure the correct host system virtuals are called. If there's a better way to do this please let me know (no, merging everything back into one class and doing lots of ifdefs will just be too messy once every function has 3 or more different paths depending on host system). 2) During init work through a hierarchy of potential country codes, falling back to C if all else fails. 3) Under Mac take a snapshot copy of the Mac Locale object as at KLocale construction, provide a utility function to return a required Mac locale setting as a QString, and use the utility to return the Mac country setting. 4) Under Windows record the Windows Locale ID as at KLocale construction (but not the actual settings?), provide a utility function to return a required Windows locale setting as a QString, and use the utility to return the Windows country setting. 5) Under KDE, call the QLocale::system().name() method and parse the country from there. This method supposedly applies some intelligent heuristics if the locale does not explicitly include a country, e.g. locale with only a language of "de" would imply a country of "DE". Note this method is affected by environmental variables. 6) Add validation checking to ensure country is only ever set to a value we support. Questions: 1) Should the Mac and Windows country methods pay any attention to environmental variables? Or do the system calls do that already? 2) Does KDE Windows handle the global locale differently to Linux? AFAIK under Linux each time an app runs a new instance of KGlobal and KLocale gets created just for that app run, so I can change the country and the next time the app starts it picks up the new country setting. Under Windows my kDebug statements appear to show that only the first run of any app causes a new KLocale to be initialised, I actually need to kill klauncher and kded4 before I can force any app to pick up a new country? Diffs ----- /trunk/KDE/kdelibs/kdecore/localization/klocale.h 1159613 /trunk/KDE/kdelibs/kdecore/localization/klocale.cpp 1159613 /trunk/KDE/kdelibs/kdecore/localization/klocale_kde.cpp 1159613 /trunk/KDE/kdelibs/kdecore/localization/klocale_mac.cpp 1159613 /trunk/KDE/kdelibs/kdecore/localization/klocale_mac_p.h 1159613 /trunk/KDE/kdelibs/kdecore/localization/klocale_p.h 1159613 /trunk/KDE/kdelibs/kdecore/localization/klocale_win.cpp 1159613 /trunk/KDE/kdelibs/kdecore/localization/klocale_win_p.h 1159613 Diff: http://reviewboard.kde.org/r/4915/diff Testing ------- Tested under openSuse with LANG = en_GB and various values in kdeglobals and it works. Tested under Windows with different locales set in the Control Panel and kdeglobals and it always returned a country (but see question 2 above). Not yet compiled or tested under Mac, still trying to build a dev environment there, but will be tested before committing. Thanks, John
_______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
