[KDE/Mac] Auto-detect KLocale Country

[John Layt]

On Friday 06 August 2010 10:46:56 Mike McQuaid wrote:
> Looks interesting. The Mac side looks fairly sensible to me but I wonder
 if
> you can't just use QLocale::system() as a starting point? Do the system
> objects give you far more information?
> 
> Sorry, just being ignorant here. If they do give you much more information
> then it looks like a good approach to me.

Yes, using QLocale is an option and would save us the maintenance burden,
e.g. just fall-through to the same method we use in Linux, but there could
be issues if using QLocale for other settings.  There would still need to be
a translation layer between Qt and KDE, so Qt would translate settings from
Mac format into Qt format and then KDE would translate the Qt format into
KDE format, which could be a performance hit and provide unexpected or
 incompatible results that don't fit the KDE way of doing things.

For example, the date formats returned by Mac are in POSIX format (e.g. ISO
date = "%Y-%m-%d), but Qt translates these into their limited sub-set of the
Unicode format ("yyyy-MM-dd"), and we would then have to translate that back
again into POSIX format for use within KDE, a process that would be lossy
 and inconsistent.

On the other hand, something like Page Size might be better coming from
QLocale as we do use the Qt page size enum and would save us coding dozens
 of translations.

Calling Mac/Win directly gives us maximum control over everything, but using
QLocale would mean only having to implement a single translation layer for
 both platforms.

I'm also not sure that calling the static QLocale::system() method would
provide us with consistent formats during the run life of the app, e.g. if a
user changes settings what does it return? In KDE it is assumed that your
locale details remain constant for the run life of the app so we would have
to have our own instance of QLocale embedded to lock the settings in, and
even then looking at the Qt code it may not do that.  That's something I
 need to investigate more, but doing it ourselves is probably more reliable.

We might be able to mix the two methods, using whichever one is best in each
case, but I think I would prefer a single clean and consistent
 implementation that gives us maximum control.

Another area that needs thought is whether to do shallow integration (like
in Qt) or deep integration.  For example with date formatting do we just use
the Mac date format strings to call the KDE date formatting code, or do we
call the actual Mac date formatting code instead?  I suspect that will need
 to be decided on a case by case basis.

Cheers!

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-mac/attachments/20100806/bf22a3be/attachment.htm