Troubles with reports in current SVN

Christian Stimming stimming at tuhh.de
Sun Mar 19 17:03:06 EST 2006


Has anyone been using the reports in current SVN seriously? I haven't so far, 
and what I saw when I tried this the last days gave me a bit of trouble with 
our current reports. I'm almost inclined to activate my "report-generating 
monster" activity... below is a rant about my initial try on reports in SVN.

Our reference for the handling and features of the reports must be the 1.8.12 
version. If we lack any of the features that have already been there, we 
better have some very good reason why it is better this way. If we don't have 
a reason, anything including reverting the report code to the 1.8-branch code 
might be an option. 

Here are some of my troubles with the current reports:

- The menus for "Assets&Liabilities" and "Income&Expenses" are too full; you 
don't find the report you were looking for, unless you knew in advance it has 
to be in that menu. Admittantly, this was a problem in 1.8 as well. In SVN 
the "A&L" menu has 12 entries (in 1.8, 10); "I&E" has 11 (1.8 had 9). The HIG 
doesn't give a strict limit. It talks about a maximum of 15 entries for the 
whole menu, but when talking about grouped menu items, it says each group 
should have 2-5 items, which is less than 12. We should try to introduce some 
grouping there...

- The text reports are *significantly* slower than in 1.8; e.g. the current 
"balance sheet" takes 8 secs with the standard options and in 1.8 this was 
3.5 secs; same for the "account summary"; the current "income statement" 
takes 12 secs and it used to take 5. This is too much. I can't believe 
doubling the runtime is technically required here -- I know the 1.8 reporting 
code wasn't optimized for efficiency at all, but it nevertheless gave the 
correct values. I can't see what new features in SVN would justify this 
significant slowing down here. Especially since a response time of 3-4 secs 
can still be tolerated by the user, but 8-10 secs is really too much. IMHO 
this whole new reporting should be up for discussion here, potentially 
including a revert to the 1.8 status.

- Some of the text report changes by David Montenegro in June/July 2004, 
mainly in r10078, seriously reduced the feature set of the balance sheet, 
account summary, and income/expense statement (now called income statement). 
For example, the relative date "today" is unavailable in the account summary 
anymore, making it unusable as a "daily startup report" which was one of the 
key features it used to provide.

- The design of the text reports has been changed considerably by the 
abovementioned change, and IMHO not for the better. The account hierarchy 
used to be shown by different indentations (using different COLSPANs in 
HTML). Now directly uses a HTML table without COLSPANs resulting in an 
extremely large indentation, which is IMHO just plain ugly and you don't have 
a good overview anymore. Maybe we need a vote about which one is prettier? 
Did we have a large number of complaints about the 1.8 way of indentation? I 
clearly vote for the original approach. This may be made a preference, but it 
would be even better to really decide which one would fit the majority of 
users better.

- A bunch of newly introduced options are totally non-understandable. The 
options in the account summary for "Display" -> "Parent account balances" 
probably just needs some improved wording; however, concerning options like 
in the income statement "Entries" -> "Closing Entries Pattern" we can 
outright forget that anyone except the original author understands what they 
are supposed to set, let alone use them. I'd vote to remove these "Entries" 
option tab right away. If you have been able to make serious use of it, all 
right, speak up now and I'm proven wrong. But otherwise I think these options 
are fine for its author but should not be released to the general (non-geek) 
public. They should be removed in SVN.

Well, enough ranting for now. At least the graphical reports didn't change its 
speed or its options, they only look slightly different, and maybe we should 
tweak the default colors a little (e. g. copy Guppi's default colors into 
gnucash)...

Christian


More information about the gnucash-devel mailing list