[Kde-finance-apps] First appearance of Alkimia in the KDE SVN repository

[Thomas Baumgart]

Hi,

on Tuesday 25 May 2010 Klaas Freitag wrote:



> Am Sonntag 23 Mai 2010 15:11:33 schrieb Thomas Baumgart:
> 
> Hey,
> 
> Thomas, one of the first real sunny sundays of 2010 and you sit in front
> of the computer and do finance math - great :-)

Hmm, I just committed it :)  It was written before when there was fog, rain 
and/or storm outside :D

> Thanks, I am really happy about seeing something moving forward. Seems like
> even kraft can become a solid app math wise with your help :o)

That's what we try to achieve.

> > I just added some initial code to the Alkimia directory
> > http://websvn.kde.org/trunk/playground/office/alkimia/ of the KDE SVN
> > repository.
> >
> > It's not much, but I promised to work on the general object to represent
> > values.
> 
> Which is cool, but also quite some complicated code, I hope I may say that.

Is it really complicated? I think this is some straight forward stuff.

> Its not that I can not understand it but I wonder if why we need that much
> functionality in a base class. I am sure you have thought about that, but
> let me ask some questions:
> - The AlkValue constructor handles the '5 8/16' format. Where is that used
> in practise?

We've seen it as price information in QIF files, something we want to import 
from other applications.

> - Later on we remove invalid chars from the string, isn't that too risky?
> For example, what would the input "0x1F" result after all non digital
> chars have been removed?

It's not meant to handle hexadecimal values.

> - the negative sign is searched within the entire string, is that correct?
> What if one comes with something like "5-3" in hope that AlkValue
>  calculates to 2?

I have that in mind, but don't support it right now. In that case, I want to 
do things like "=2*balance(account-this-and-that)".

> Wouldn't it make sense to have a flag that indicates if "dangerous"
> operations such as the ones described above have taken place or not?

This can also be handled by the application or a derived class.

> And what about passing a KLocale to the constructor instead of just
> the decimal sign? It could default to the default locale and other
> information than just the decimal sign could be taken from it, for
> example the toString method.

Sorry, no. The locale is not part of AlkValue. You have to be able to read in 
data in any locale. As Alvaro pointed out already, there is a lot of knowledge 
in the class that we learned the hard way in KMyMoney, like having a German 
locale in the UI but the QIF file written by the German version of your old 
finance app you want to get rid of is written using a US locale.

The toString() method is not meant for UI purposes but for serialization. It 
does not need locale information. I want to keep all the formatting in a 
different spot.

> Please, this is of course not meant offensive, I think we should be
> open in discussing on a code base to achieve the best for our project.

I don't read your lines as offensive. Of course there is RFI (room for 
improvement).

> Of course it is great to see this code coming in and making up the
> prject. Thanks again, Thomas.

Would love to see it being used in Kraft.


-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
Please avoid sending me Word or PowerPoint attachments.
 See http://www.gnu.org/philosophy/no-word-attachments.html
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-finance-apps/attachments/20100525/6599ebf2/attachment.sig