[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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel