Bug or feature?

[Donald Allen]

On 8/27/07, Josh Sled <jsled at asynchronous.org> wrote:
> "Donald Allen" <donaldcallen at gmail.com> writes:
> > To fix this, I did a search on the name of heating oil supplier, which
> > correctly turned up all the transactions involving them. Now I want to
> > double-click (to select) on the (correct) debit side of an older
> > transaction, copy it (ctrl-c) and then double-click on the debit sides
> > of the incorrect transactions, one by one, and paste the correct
> > expense account into them. The trouble is that when I double-click on
> > the source of the correct account, a blank line appears immediately
> > after it, shifting all subsequent transactions down by one line. Then
> > when I go to double-click on the debit side of an incorrect
> > transaction, the extra line disappears from after the (earlier) source
> > transaction and appears after the destination transaction. This shifts
> > the latter transaction up by one line after my first click and the
> > second click is therefore in the wrong place (the credit side). So,
> > for what I am trying to do, the UI is making my life more difficult.
> > Before I submit a bug report, I'd ask one of the developers to explain
> > the rationale for this behavior (the addition of a line following a
> > selected transaction), since there may be other considerations that
> > justify it.
>
> I can reproduce this, but I don't know if I'd call it either a bug or a
> feature.  It is just what it is.
>
> The blank line is certainly a feature; the selected transaction always has a
> place to enter new splits.  This particular interaction mode you're using
> does exhibit a problem in selection, when the blank line disappears and the
> lines are shifted on the first click, then the second-click selects the
> now-shifted split below it.
>
> As a work-around, I'd recommend not double-clicking.  Just use the down-arrow
> to move between the transactions and splits.  As you do this, the account
> name will be selected, as well, letting you paste the new account in.  It'll
> probably be way faster than using the mouse, as well.

Very nice. Thanks for the suggestion.

The UI is optimized in this instance for one class of interactions
(adding splits) at the expense of another, an unavoidable choice since
the two classes of interaction want opposite behavior from the UI. I
can't argue that what gnucash is doing is wrong, but I would suggest a
preference item for toggling this behavior on/off in search windows.
In my own style of use of gnucash, I don't think I've ever added a
split in a search window; I do that sort of thing in account
registers.

/Don


>
> --
> ...jsled
> http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
>
>