My comparison between GNUcash and Skrooge (if anyone is interested)

[Geert Janssens]

Alistaire,

Thank you for your video. I watched it because I'm always curious to 
learn how others perceive GnuCash. In my view, it raises some valid 
points and at other times it contains some misinterpretations.

1. As others have noted already, most reports where it makes sense will 
have a date filter. If you find any that doesn't, you're invited to 
report this. Preferably via our bugtracker (bugzilla) [1].

2. Your following comment, related to reports:
 > ME: my version does not show the gear icon.

The icon on the toolbar is theme dependent, but just hovering the mouse 
over the icons would have revealed one button to be called "Edit report 
options". You don't open a report in your video either. That would have 
given me the opportunity to tell you what the icon looks like with the 
theme you have chosen. In any case: when a report is open, you can edit 
the report options using "Edit->Report Options".

 > 3..GNUcash to make a custom report is much more complex than Skrooge 
which
 > has a wizard-like reporting. A report can be generated from a search 
as well
 > in Skrooge.

I don't know how Skrooge custom report creation works. Yet I also agree 
that this is an area that can be improved in GnuCash. Help is welcome.

4. In the video you generally claim multiple times that the GnuCash 
transaction entry interface is "messy" and the Skrooge one is much better.

In my opinion, you are trying to compare two fundamentally different 
input systems here. And on top of that, the two applications are using a 
fundamentally different basic concept, which heavily influences how data 
input should be done: GnuCash does double-entry bookkeeping as you 
mention already in your video. Skrooge does not. GnuCash has chosen for 
an in-place editing mechanism for rapid data entry. Skrooge uses a model 
where you have an overview of entries and an edit panel below. I 
personally prefer the GnuCash method. I quickly tested Skrooge, and at 
first sight, Skrooge's method of input would require way too much 
switching between keyboard and mouse to be efficient for me. I'm saying 
this mostly to show that "better" can also mean "preferred" and be a 
very personal interpretation.

5. You also point out that you can't double-click to expand a split 
transaction. Something that would be easier in Skrooge.

In the video you are double clicking in the description field of the 
transaction. That is an editable field, accepting user input (like 
typing text, selecting text and so on). Based on the concept of in-place 
editing, double clicking on such a text field should select the text. 
That is expected behaviour for any editable text field. Changing that 
behaviour so that a double click would expand the splits would certainly 
cause a lot of other reactions ("double click doesn't work anymore !"). 
Did you consider this ?

On the other hand, I am open for improvements, so your comment did make 
me consider if we can do better. I think we can. A possible improvement 
I see here is changing the behaviour of double-clicking (or even 
single-clicking in the transfer column if the transaction is multi-split 
(by which I mean having more than 2 splits). In such situation, the 
splits could be shown automatically. If you like this, I propose you 
make a new feature request in either bugzilla or on the GnuCash' 
uservoice page [2] so the idea doesn't get lost.

6. There was a moment in the video where you had trouble correcting a 
transaction you entered wrongly. You had entered 50 in the deposit 
column instead of the withdrawal column. The first issue you raise here 
is that while the splits are expanded, you can't change the transaction 
amount anymore, but instead you first have to collapse the split list again.

In my opinion, this is mostly a matter of misunderstanding the input 
dynamics of GnuCash, again linked to the double-entry concept that is 
the basis for all. First off, there is no such thing as a "transaction 
total" in GnuCash. This is a concept that you find in qif files and 
likely in Skrooge as well in one form or the other. In GNuCash, each 
transaction's total equals 0, or they wouldn't be balanced according to 
the double-entry principle. So what you see in the deposit or withdrawal 
column is not a "transaction total", but the part of the transaction 
that is relevant for the account at hand (TSB-00 in your example). For 
simple transactions (with only two splits), this equation is simple. 
What flows out of one account, flows into the other account. For 
multi-split transactions, this becomes less obvious and impossible to 
display on one line. Hence an extended view of the whole transaction is 
offered in the split transaction view. Once the split list is expanded, 
all transaction details other than date and description are in the split 
list. At this point you can directly edit each split that is part of the 
transaction, including the one in the account at hand, TSB-00 in your 
example (third split). There is no need to close the split list first.

Perhaps this can be improved, by allowing to change this value both on 
the split level and on the transaction line itself in split view. I 
don't know if that would be an improvement or confuse things more and 
how hard it would be to implement such a feature. I have no strong 
opinion here.

7. Next complaint you make when you enter 50 in the withdrawal column to 
correct your mistake. You seem to have to do it twice.

I'm not sure you understand what happened there and why. At first sight 
you seem to be misunderstanding the power of GnuCash' data entry model. 
There is a column for deposits and one for withdrawals. This double 
column notation could also have been done with only one column in which 
you enter positive or negative numbers, which is closer to what Skrooge 
does. This is a design decision that was made way before I got involved 
in GnuCash. The reason why is not relevant here.

But having two columns enables the user to enter a value in both 
columns. If you enter a transaction with say 50 deposit and 30 
withdrawal, what would you think should GnuCash do with that ? The 
choice was made to let GnuCash simplify such a transaction to net 20 
deposit. This fits well in the philosophy that each amount field in 
GnuCash can do and does calculations. So if you enter a value in both 
columns, GnuCash will calculate the difference and retain that as net value.

I deliberately chose two differing amounts in the example. In your 
video, you entered 50 deposit (first time) and then 50 withdrawal in an 
attempt to correct the transaction, but you left the 50 deposit in 
place. So you told GnuCash the transaction split for TSB-00 is now 50 
deposit and 50 withdrawal, which it diligently recalculates to 0 (no 
value in either column). At that point you enter 50 again in withdrawal 
which is then the end result, because no further calculations have to be 
done.

8. The main point you wanted to make though was that GnuCash doesn't 
save percentages or more generally formulas, when reusing a previous 
split transaction.

This is true and could be considered a missing feature in GnuCash. I'm 
not sure if this is something that can easily be implemented. I would 
fear not, because at first sight it would require changes straight down 
into the file format and all the core accounting logic.

9. GnuCash can only export accounts to xml.

Not quite, but close. You can also export reports to html (when the 
report is open, there will be a menu item somewhere and a button on the 
toolbar).

Other than that, there are not many export options indeed. I guess 
nobody volunteered to implement additional exporters. Help is welcome.

10. Similarly, the import options are limited, though there are more 
options than for export already.

The same goes here. Notable absent are importers for Skrooge, KMymoney 
and other open source finance and accounting programs. Again, nobody 
sent in patches to implement this. Help is welcome.

11. You mention (but don't demonstrate) that csv import was not working 
well. It's hard to comment on that without additional detail. But here's 
a sneak preview: the csv importer has been rewritten in development, so 
hopefully this will be a thing of the past once the next major release 
is out. (I don't know when that will be, no).

12. Early in the video you make a statement in the line of "Both are 
open-source programs, which means you don't have to pay for them". I'm 
afraid you are doing the whole open source community a disservice by 
phrasing it like that. Both statements are correct independently. 
GnuCash is open source (or technically free software, but I deliberately 
skip over the difference here). And GnuCash is available free of charge. 
But one is not the consequence of the other, by no means. The true value 
is that the *source* is freely available, allowing anyone to modify it 
at will, review it, send in patches,... That the binary application 
itself can be used without having to pay for it is an added bonus, but 
not necessarily always like that. It would have been more correct if you 
formulated it that way. That would help other new users to make this 
distinction correctly early on.

13. Some comments on these statements from your mail:
 > 3..GNUcash does not accept standards keys. For example when you have 
a tab
 > open the usual way to close it would be Ctrl-F4, but you must use the 
close
 > button! This inconsistency is consistent through GNUcash and IMHO a bad
 > decision from the programmers as its very easy to implement a user 
friendly
 > interface, which would make a real difference to user experience.

On what system is Ctrl-F4 "the usual way to close a tab" ? Never mind, I 
looked it up [3]. It seems more like a browser convention than a 
universally standard key. And even as a browser "standard" it does not 
work on Linux/KDE by the way. Ctrl-F4 switches virtual screens in 
Linux/KDE and it has been like that as long as I can remember. According 
to the same wiki page, a more general default key combination is Ctrl-W. 
Have you tried that ?

What other non-standard keys does GnuCash not accept ? Perhaps some of 
them can be improved.

 > Derek. The point of the video is to demonstrate what most new users would
 > expect from an accounting program <u>mainly with the user interface</u>.
 > Unfortunately sometimes programmers ideas can be fixated on how 
<u>they</u>
 > consider the user should work, not on how the user would find it 
easiest.

I dislike the "user knows best" mantra as much as "developer knows 
best". GnuCash is a community project in which both users and developers 
can formulate ideas and suggestions, which can then be openly discussed. 
Both are valuable.

And can I kindly ask you to be careful with using generalizations such 
as "most new users" when you are expressing your personal opinion ? I do 
value your opinion especially as a new user, but stick to calling it as 
such. Let other users chime in if they support it.

 > This is an area of GNUcash and I have commented on several times 
lately and
 > in the past, and as an ex programmer myself I know just how easy it is to
 > change the user interface.

The last part of your statement can be considered very arrogant (unless 
you meant it jokingly, which I couldn't determine from the sentence 
alone). I had to rewrite my answer several times in an attempt to answer 
as neutrally as possible.

I'm glad you know how easy it is to change the user interface. If you 
are serious about that then I equally seriously invite you to write some 
patches for the easy fixes. You will be doing all users a favor.

Geert

[1] http://wiki.gnucash.org/wiki/Bugzilla
[2] http://gnucash.uservoice.com/
[3] http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts