Vanishing transactions and log file

[Donald Allen]

On Tue, Apr 1, 2008 at 11:55 AM, Ross Boylan
<RossBoylan at stanfordalumni.org> wrote:
>
>  On Tue, 2008-04-01 at 10:51 -0400, Derek Atkins wrote:
>  > "Donald Allen" <donaldcallen at gmail.com> writes:
>  >
>  > > Thinking about this some more, one *could* imagine the atomic particle
>  > > of the basic register being a transaction, not a split. Then, in a
>  > > case like this, you would see one entry, not two. I think for most
>  > > people (myself initially, and probably for Ross) this would be less
>  > > confusing. But it would also be less informative, as I mentioned in my
>  > > previous message, because without expanding the splits, you would not
>  > > know that there were two splits involving the account (for which
>  > > you've displayed the basic register). I prefer it as it is, having
>  > > figured it out after my first "what's this?" reaction and come to
>  > > realize that it makes sense.
>  >
>  > True, one COULD imagine this, but then you have a problem.  When
>  > displaying/editing the split-specific data, which split's data do you
>  > show/edit?  Yes, it might sound nice to be able to combine the values
>  > into a single line, but what do you do if you try to change the
>  > number?  See, there are MANY reasons GnuCash does it the way it does.
>  > :)
>  >
>  > > /Don
>  >
>  By the way, I've also been confused by the rules regarding the comment
>  or note in the header line vs the notes on the splits.  In some views
>  there seem to be 2 header lines (top one with the date and most of the
>  key info, 2nd one for the note, I assume).  I think there is a notion of
>  a "transaction comment" distinct from a "split comment", but the
>  contents of the transaction and split comments seem to get copied
>  between each other (in the display) following some rules I haven't
>  understood.
>
>  Back to the main question, I'll repeat that a design that invites
>  misinterpretation is not a good design.

I'm not sure I agree with that. Sometimes people find A Better Way
that breaks with previous convention and, because it's unfamiliar,
gets misinterpreted until it sinks in. Something doesn't have to be
instantly accessible to be good (try reading Faulkner or Joyce).

I'm sure many of the first folks were pretty confused when they first
got handed an HP calculator in the early '80s. The folks at the
Congress of Vienna thought the Beethoven 7th Symphony had been written
by a "drunkard" (they *did* like his Wellington's Victory hack that he
wrote in two weeks for the money). They were also confused in Paris in
1913 when Stravinsky's Le Sacre du Printemps caused a riot at its
first performance (even brilliant people  like Saint-Saens and Puccini
hated it; Ravel got it; it is now widely considered *the* masterpiece
of 20th century music).

While I hasten to add that I don't rank Gnucash with Beethoven's and
Stravinsky's achievements, it was built by some pretty smart people.
I'm suggesting that when gnucash's behavior seems odd and
unconventional, take a deep breath and try again to understand why it
does what it does. More often than not, you'll end up saying to
yourself 'ok, I get it -- this is makes sense".

/Don

 I also agree that there are
>  times one would want to see the splits.  So far, we've been going back
>  and forth about what to do with the register as it is now, but this
>  suggests that an adequate solution might involve a different approach
>  altogether.  Unfortunately, the only thing that immediately comes to
>  mind is a small tweak.  I did notice a comment about future directions
>  for gnucash saying that the current design was oriented toward
>  replicating a paper checkbook, and that was not optimal.  So maybe
>  someone else already has some ideas.
>
>  The small idea is to replace the current views (basic/autosplit/journal)
>  with splits vs transactions views.  The former would be a lot like the
>  current "basic" except that it would either be read only or it would do
>  something special if you tried to delete or alter a split.
>
>  The problem with that is that it makes the typical case, a transaction
>  involving exactly 2 splits, awkward.
>
>  Ross
>