register rewrite

[Chris Shoemaker]

[adding Jeff Green to cc]

On Mon, May 21, 2007 at 11:48:06AM -0300, Peter Selinger wrote:
> Hi,
> 
> I have tried the new register rewrite branch. It looks very nice; many
> thanks to Chris. 

Peter,
        Thanks for the review.  I've unfortunately had very little
time for the register rewrite recently.  However, the good news is
that Jeff Green has been accepted as a GSoC student specifically for
this project.  And that work should start up quite soon.
        I'll just make a few comments on the points below...        

> I have a few minor comments and suggestions.
> 
> * numbers in the register view should be right-aligned

This should be quite easy.  As a bit of an aside, does anyone know if
this needs to be locale-dependent?

> * it would be nice if the transactions were sorted by date by
>   default; the current default seems to be random order?

Date certainly should be the default.  IIRC, there was a slightly
related "bug" in GtkTreeModelSort, where the order among transactions
having equal values of the sort key would be determined by the order
in which they had last emitted an event - and since cursor navigation
triggers events, the most-recently navigated-to transactions "bubbled"
to the top of the group of transactions with equal values of the sort
key.  It was (is?) quite annoying.  If GtkTreeModelSort still exhibits
this behavior, we'll have to work around it somehow.

> * a useful feature would be if double-clicking on the words 
>   "-- Split Transaction --" split the transaction, and double-clicking 
>   on a transfer account opened that account.

Also pretty easy to do.

> * in the "debit" and "credit" column in split transaction view, I
>   would like to see that amount, and not the value, of each split. 
>   This is more transparent for multi-currency transactions. (I.e., it
>   is more useful to know that you have exchanged CAD 40 for AUD 50,
>   than that you have exchanged CAD 40 for CAD 40 in an AUD account).

The value field is just there for debugging, and hiding it is easy.
Notice that it is _not_ editable, in rather stark contrast to the
current register.  The ability to even see and edit the amount is, as
you know, one of the reasons for the register rewrite in the first
place.  Jeff, I recommend that you review this thread:
http://lists.gnucash.org/pipermail/gnucash-devel/2007-February/020008.html
and the two documents that Peter links.  Correct multi-currency
support is one of the most important requirements for the register
rewrite.

However, there are still some issues to be addressed regarding smooth
data-entry into the amount field.  For example, is the currency symbol
visible during entry?  If you've entered something for an amount, and
then you change the transfer account to an account in a different
commodity, should the (probably invisible) value stay the same and the
amount change automatically? or vice versa?  (Aren't they both
annoying in certain cases?)  How can we optimize for the more common
single-currency cases, while giving multi-currency users the power
they need?

> * in the "price" column, the display of exchange rates as rational
>   numbers (1 + 971 / 4118) is mathematically accurate, but not very
>   user friendly.  Since it's a derived quantity anyway (not stored
>   separately by the engine), I am not sure why that extra accuracy is
>   needed. Perhaps 4 decimal digits would suffice?

That's very easy to fix, but did you notice that the price field is
editable, even though it's a derived quantity?  Its quantity is
factored into the other fields.  I think it'd be nice if
multi-currency (or stock - exactly the same issues) users at least had
the option of editing all the quantities directly in the register -
without a dialog.

> * the old "edit exchange rate" button is still there, but does not
>   seem to do anything. It would be nice if it still worked (so one
>   does not have to display the Amt/Val/Price columns at all times.

Yes, that'd be nice, too.  Not too hard.  BTW, I don't think
cut-copy-paste work either.  That's a little trickier, because it's
probably a very bad idea to reuse the old register's implementation of
cut-copy-paste.

> * keyboard entry in the account view leads to characters being typed
>   into a little box at the bottom right of the corner. It looks like
>   it's meant to be a search function, but it doesn't do anything
>   except jumping to the first transaction.

I don't remember seeing this, but I haven't tested with more recent
gtk+.  I didn't hook up the tree-view's native search functionality to
the register, but that would be _really_ nifty.

> * it's now possible to split-view several transactions at the same
>   time. Is there an easy way to unsplit them all? The old View ->
>   Journal Style etc. buttons seem to be gone. 

I call these three "expansion policies" and there are pretty easy to
implement.  I also kind of like the flexibility they give, for
example, to have only the currently-edited paycheck transaction and
the last paycheck transaction 10 transactions back open, with
intervening transactions collapsed.

> * pressing "return" while editing a transaction does not commit it,
>   nor does there seem to be an easy way to commit a transaction (other
>   than clicking on another one and answering the "Save the changed
>   transaction?" dialog. 

Hmm, I'm pretty sure that used to work.  Well, it's definitely
supposed to.

> * Tabbing through a transaction also brings up the "Save the changed
>   transaction?" dialog, even if the transaction has not been changed.

This is definitely a problem, and a little trickier one.  The intent
is to let the user begin editing the cell immediately after navigating
to it - without, for example, having to press space before editing.  I
accomplished this by entering edit mode after every tab to an editable
cell - and then I had some hacks to prevent the transaction from being
dirtied unless the cell was actually edited.  I no longer think that
approach is the best way to go.  I think a better way is to let
navigation happen in the unedited state, but then automatically enter
edit mode upon the first alphanumeric keypress - while still servicing
that keypress, too.

> 
> -- Peter

I really appreciate the review.  It often helps to have another set of
eyes on something.  I find two things especially encouraging - first,
that the major things that stick out to you are pretty much the same
major things that I knew had to be done; and second, that so many of
these things are relatively easy to implement.  I think Jeff is going
to have a lot of fun with this project, and we'll hopefully be looking
at a shiny new register by the end of the summer.

-chris