[Kmymoney-devel] Simplifying the transaction form

[Thomas Baumgart]

Hi,

on Wednesday 25 August 2010 03:10:13 Alvaro Soliverez wrote:

> Hello all,
> this is a mail to start a discussion, propose some alternatives and do
> something about it or maybe do nothing if we feel comfortable with the
> current situation.
> 
> During the port it was clear that the code underlying the transaction
> form (eg. the widgets where you enter a transaction on the ledger
> view) was very complicated, and some design decisions were made at the
> time that are no longer valid on KDE4.
> 
> For example:
> - different widgets are used for viewing and editing. To deal with
> this, several tricks have to be made otherwise the widgets are visible
> behing one another

True. That was the only way in KDE3 to get an edit widget into a QTable.

> - the transaction type (deposit, transfer, withdrawal) has each its
> own tab, which leads to copying the widgets from one tab to the other
> when changing the transaction type. Changing that to a combobox or a
> radio button would avoid several issues and remove a pile of code.

Well, this is sort of true. Actually, none of the tabs is used for widgets. 
They are kept in their own Q3Table. The tabbar itself is copied though when 
switching from 'view' to 'edit'.

> - regular transactions and investments have different widgets for the form

Yes, it's a bit clumsy right now with all the options available for 
investments. Having a cleaner UI would be cool.

> - the visibility of the widgets is problematic. we still have a bug
> open on that for investments

Right.

> - automatic transaction fill has proven to be troublesome

Yes, but that is more of a design problem between the widgets and the 
application. I hope, that using an MVC based approach helps us here.

> For the future, we have some features related to the transaction form,
> like tags and transaction templates. Having a more lean and
> straightforward code would help a great deal to get these features
> into the existing code without causing big headaches.
> 
> How I see this change happening:
> - Use the same widgets for viewing and editing (disable as needed)
> - Hide the widgets that are not needed

We do that already today (see the account widget which is not visible during 
transaction entry but is present during schedule entry)

> - Use layouts to have the widgets rearrange themselves shen hiding/showing
> - Revisit usability issues in the process (transaction date, anyone?)
> 
> Perhaps we should do it first for regular transactions, and later for
> investments.
> 
> My gut feeling is that we should do this before trying to add even
> more features into the ledger or we'll suffer swift punishment. Today,
> I feel dizzy when I have to fix in there.

Yes, we should come up with a new design that covers all the aspects we need 
before we touch it code-wise. This has also some influence on the register or 
ledger itself, as we also have the method to turn off the transaction form and 
enter all data in the register directly. Today, the same object (transaction 
editor) is used for both methods to avoid code duplication. This is one of the 
reasons why we also have different widgets for displaying and editing.

I'd love to see this changed so that we have a cleaner design. So I guess it's 
time to get out the UML tools of our choice and do some design. Or should we 
start with the requirements so that we all know what we are talking about? I 
think it would be a good exercise so that *all* of us know what's needed and 
that we don't forget anything.

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
'Knowing a computer language is neither a necessary nor a sufficient
condition to know how to construct a computer program' -- J.R. Tyrer
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kmymoney-devel/attachments/20100825/17b8e114/attachment.sig