[Kmymoney-devel] Simplifying the transaction form

[Alvaro Soliverez]

Hello,

On Wed, Aug 25, 2010 at 3:35 AM, Thomas Baumgart <thb at net-bembel.de> wrote:
> 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.

Perhaps we can try a QDock. KOffice makes extensive use of them and
they seem to work for the most part.
>
>> - 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.
>

Yes, perhaps we could start a page with the requirements on the wiki,
and then make a design from there.