> On 2010-08-11 20:48:32, Albert Astals Cid wrote: > > The doInit parameter looks a bit ugly, can you just create a "Unix" leaf > > class and then make all leaf classes call init and the base class never > > call init?
You're right, far easier and way more elegant. Amazing how you sometimes can't see the obvious when it's right in front of you :-) - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4915/#review7004 ----------------------------------------------------------- On 2010-08-06 09:03:23, John Layt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/4915/ > ----------------------------------------------------------- > > (Updated 2010-08-06 09:03:23) > > > 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
