[Kde-finance-apps] Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Friedrich W. H. Kossebau]

Hi John,

Am Mittwoch, 6. Januar 2016, 10:07:55 schrieb John Layt:
> On 6 January 2016 at 07:12, Friedrich W. H. Kossebau <kossebau at kde.org>
> 
> wrote:
> > 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?
> 
> Hi Friedrich,
> 
> Apologies that the new QLocale features are taking so long,

No need for apologies, I am actually thankful for all the work you have done 
and brain cells you have invested here already, and I very much understand it 
is a highly complicated problem to model all these cultural artifacts with 
their random rules in a generic way and then also integrate with all the 
different platforms and their possible simplifications of the problem. Nothing 
I would ever pick myself to work on :)

> but it's
> proving very hard to find an acceptable cross-platform solution that isn't
> dumbed-down to the lowest feature set (i.e. Win32) and therefore useless to
> us. I've just started working on Plan D [1], each of the previous plans
> representing 3-6 months work before getting shot down. If this plan
> survives the inevitable savaging on the qt-dev mailing list then I'm hoping
> it will make the Qt 5.8 release, so perhaps a year before you could really
> use it.

Okay, glad to read that you are again going for it. Possibly a good chance for 
us currency-handling-app developers to play with the new API from the very 
beginning and give early feedback, so the final result will not leave us 
unsatisfied :)

> In the interim I'd suggest using ICU, seeing as the plan for Qt on Linux
> will be to wrap ICU anyway. It's not a pretty api, but it has all the
> features you want and you can rely on it being packaged everywhere. The
> main problem to watch out for is that there is no binary compatibility
> guarantee on the C++ api, so to be safe it's better to use the C api, but
> that unfortunately has fewer features available.
> 
> To save you some work, I do have an old draft implementation of the new
> QNumberFormatter class at [2], it works on ICU and Mac but the api is a bit
> outdated now. If you're happy to wait a week or two I'll have a new version
> of the draft api and test ICU implementation completed which now includes a
> proper QCurrencyFormatter class which you could copy.

I personally only care about Linux & similar platforms, so ICU is a fine 
dependency for me :) Perhaps in a few months Android as well, seems ICU might 
be doable there as well. If Windows & OSX are supported by ICU as well, even 
better, if some want to have Plan & Sheets over there.
So using ICU seems a good option, as it solves the currency database problem 
for what I understood.

Additional bonus, if the drafts of the QNumberFormatter classes can be used 
decoupled from the real QLocale, their API can already get some real-world 
testing in our apps. And once they are official part of Qt our code does not 
need bigger changes.

So looking forward to those QCurrencyFormatter classes you are working on. 1-2 
weeks waiting is fine, in the meantime we could look closer at the exact needs 
we have (e.g. with parsing) and compile some relevant unit test data.

> The other area still needing work is replacing KCurrencyCode for general
> data look-up tasks. I'd like to get a Qt version of it, but I'm doubtful it
> will make it in to Qt as Win32 doesn't provide the required data or api and
> I'd need to convince Qt that including all the data would be worth it. It's
> an area I'm still researching.

Never came across KCurrencyCode so far, not used in Plan & Sheets. So not 
commenting on that one. Though if such a class is redone in Qt, ideally it has 
setters or another way to create a custom object on the fly, not just a custom 
QFileInfo that could be passed to the constructor and thus the need to go via 
the filesystem, as with KCurrencyCode.
Use cases are non-ISO/non-state currencies (like digital currencies or 
local/community currencies).

Cheers
Friedrich