Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Tomas Mecir]

Hey Friedrich and others!

I've hit the very same issue in Sheets earlier that you did, and ended up
postponing that part of the porting (though I do have a local branch with
partial results). Not really sure what the best solution would be - the
problem with KLocale is that it seems to be out of sync with QLocale, so
for me at least they both report different locales/languages. Weird, that.

Anyway. I've looked at QLocale's code, and adding precision to the
formatting routines would be trivial technically - the routine called by
formatMoney supports it, so it's just a matter of adding an optional
argument to formatMoney - should even be BIC, as I understand it. Not sure
how easy/hard it'd be to get the change into Qt.

The main problem with QLocale seems to be that it essentially is a black
box - it has all the locale info we need, but we can't pull it out of it.
So if functions to return the format string, precisions, etc for the
current locale could be added, so that wrapper classes can be built, that'd
probably be all we really need.

/ Tomas


2016-01-06 8:12 GMT+01:00 Friedrich W. H. Kossebau <kossebau at kde.org>:

> Hi developers of finance apps & Calligra Sheets & Calligra Plan,
>
> (please keep cross-posting to both ml for now)
>
> I (not only with my Calligra developer hat on) would like to collect
> experiences and ideas for conversion of curreny values to and from
> strings when using Qt5/KF5, especially when porting from kdelibs4's
> KLocale.
>
>
> PROBLEM
>
> QLocale is rather limited (as of Qt 5.5):
> - no currency string parsing method
> - string formatting method toCurrencyString() does not allow
>   to control precision
>
> KLocale and its currency related methods seem the last blocker to get
> rid of kdelibs4support in Calligra in the Qt5/KF5 port. Plan uses them
> for handling the costs of resources, and Sheets for the currency
> formatted cells. And both limitations are a blocker.
>
>
> APPROACHES
>
> Long term ideally QLocale gets support in its API for that. So we
> developers of currency data handling software should organize and
> draft an API.
>
> First and short term though, until some released & wide-spread Qt
> version has the improved QLocale, I am looking for a solution
> independent of QLocale.
> Most obvious might be to duplicate all currency things from KLocale,
> which would also include duplicating the database with all currency
> formatting data. This is what I would plan to do if there is no better
> idea.
> Especially the database duplication is painful though, I would like to
> avoid at least that if possible.
>
>
> QUESTIONS
>
> How have developers of e.g. Skrooge & KMyMoney approached the issue of
> conversion of currency values to/from strings?
>
> Do you know about any activities to improve QLocale here?
>
> Seems that Calligra apps Plan & Sheets are the only KDE apps using
> KLocale::readMoney() ?
> https://lxr.kde.org/ident?v=stable-qt4&_i=readMoney&_remember=1
>
> But KLocale::formatMoney() might be used by KMyMoney, Skrooge, Kraft &
> others (did not check though if not custom code):
> https://lxr.kde.org/ident?v=stable-qt4&_i=formatMoney&_remember=1
>
> Cheers
> Friedrich
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20160106/e0f29152/attachment.htm>