Trouble With "Enter" vs. "Tab" (Again)

David T. sunfish62 at yahoo.com
Mon Nov 14 13:24:49 EST 2011


John--

I am sorry I missed the details about the Tab key moving to the next field, while the Enter key move to the next line. Frankly, to me that's not the point.


Ultimately, the point is that the Enter key "finishes the transaction edit" but still keeps the transaction open onscreen. This misleads users, and will cause them to have the kinds of troubles I experienced. I *still* don't understand the reason WHY the Enter key finishes the transaction edit. If there is a functional use-case reason for finishing the transaction edit every time a user presses Enter, I'd really like to hear it. I trying to understand this.

In the absence of such an explanation, would it be such a horrible solution to remove the closing action of the Enter key behavior altogether, and instead have the closing action attached to the empty split situation (as it currently is when the user presses Tab on an empty line)? As an end user, I would be willing to go to Bugzilla and file an RFE bug request for this change, if it seems like it makes sense.


Adding a per-transaction nag dialog will NOT help the situation, and I really don't think it would be helpful to add *another* key combination (CTRL-Enter) into the mix. I would rather see the distinction go away altogether.

As for the problem with entering capital gains, you refer to the current functionality as a "hack." That suggests to me that someone purposefully made use of the difference between Tab and Enter to convince Gnucash to behave in a specific way in this instance. Since it *is* a hack, and since you've made it clear that there are unlikely to be fixes to this, I think it should be clearly stated in the documentation that this is an issue. I have filed bug 664054 to address the documentation question.

David


----- Original Message -----
From: John Ralls <jralls at ceridwen.us>
To: David T. <sunfish62 at yahoo.com>
Cc: Users Gnucash <gnucash-user at gnucash.org>
Sent: Sunday, November 13, 2011 1:47 PM
Subject: Re: Trouble With "Enter" vs. "Tab" (Again)


On Nov 13, 2011, at 10:55 AM, David T. wrote:

> John--
> 
> As I noted, I recognize that the dev team makes this distinction. I reiterate my question: why?
> 
> Why treat the keys differently? The onscreen behavior looks exactly the same! If I use the Enter key to go off the end of a split line, Gnucash doesn't, in fact, go to the next transaction--it goes to the next line of the split. And will keep doing that as long as there is some non-null data on the active split line. This is exactly how the Tab key works as well. If you Tab repeatedly, eventually you get taken to the next transaction, and whatever special feature associated with the Enter key is triggered anyhow. So, why have this distinction at all? 
> 
> 
> Having the keys do the same thing onscreen, but radically different things in the software is troubling to me. How is the non-developer supposed to know that there is this difference, and how are they supposed to keep track of these differences?
> 
> I will note that the Help file (section 6.3) clearly instructs the user to use Tab when moving among the lines, and Enter to complete the transaction--but there is nothing that I could find that explicitly says: "In Gnucash, the Tab and Enter keys invoke different procedures in the software. The Tab key moves from field to field without committing the transaction and triggering Gnucash's transaction cleanup procedures. Pressing the Enter key causes Gnucash to check the transaction for integrity and ensure that the transaction follows double entry accounting principles."
> 
> I made that up, and I could be wrong, but calling the Enter process "the special undocumented behind the curtains wizardry" didn't seem helpful. 
> 
> Returning to the problem at hand, you note that using the Lots method might work, but I have found that this method leaves a lot to be desired. IIRC, once the lots have been managed through this, there doesn't seem to be any way of straightening them out later, should there have been an error in the original calculations.I can't recall the full specifics, but when I tried to clean up a mutual fund holding that predated my use of Gnucash by many years, I was thoroughly unable to get the lots to work out correctly, and I have simply left the mess until such time as I have time and heart to delve into it.
> 
> 
> Considering further, perhaps the issue of managing capital gains would be better served by having the sale of stocks and mutual funds processed via a dialog box, triggered from a menu item under Actions (alternatively when the user chooses the SELL action in a transaction and then leaves the field, although this would undoubtedly raise the whole Tab/Enter issue again ;) ). 
> 
> 
> The dialog box would prompt for:
> 1) Number of shares
> 2) Sale price
> 3) Commission (with an associated account, default set by preference/last used)
> 4) Account to receive proceeds (drop down account list, default set by preference/last used)
> 
> 5) Gain/Loss (with an associated account, default set by preference/last used)
>     Additionally, (if this makes sense) include a button to calculate Gain/Loss for you. This button would trigger a process that would allow you to choose between FIFO or LIFO calculation of gain. ISTR that there was someone wanting this functionality a couple of years ago.
> 
> 
> [I tried to mock this up using Glade, but I found the Glade interface... challenging. I figured getting some kind of description here would be a start, anyway.]
> 
> 
> I don't know whether I have covered the necessary options fully here, but I think this is at least a start in the right direction (at least from my perspective).

Well, as the saying goes, "patches welcome". I agree that lots has its problems, and like you I prefer the extra control from manually handling capital gains. I do get a bit more practice at it, as I trade several times a month.

You're mistaken about the behavior of Tab and Enter when editing splits.

Tab: Moves to the next field to the right in the current split. If it's the last field, moves to the next split, creating a new one if there isn't one -- unless the one it's leaving is blank, when it will in fact do the same thing that Enter does. When exiting a credit/debit field, causes a trial balance of the transaction, with little gray 'x'es in the credit/debit fields if it's out of balance, and a balancing entry in the last (otherwise blank) transaction.

Enter: Moves to the first field of the next split, regardless of which field you were in. If there is no next split, proceeds to the next transaction. In any case, it finishes the transaction edit, and any imbalance is posted to a toplevel account called Imbalance-CUR, where CUR is the currency of the transaction.

I suppose that we could have an "Are you sure?" dialog box pop up before closing an unbalanced transaction, with an over-ride key binding (<control>Enter, perhaps) to indicate that you know that it might be unbalanced and you just want to get on with it. But I'm not signing up to write that.

The gain/loss calculation in your dialog box is what the lots function does except that there's only FIFO because no-one has written any of the others (LIFO, selected lot, and average cost). 

Sorry, there aren't any quick solutions.

Regards,
John Ralls



More information about the gnucash-user mailing list