Reporting system

[Christian Stimming]

Hi Tim,

Am Donnerstag, 7. Juli 2011 schrieb Tim M:
> As you know I have done a little work on the reporting system to try to get
> some form of standards-compliance working.  I have been looking through
> previous mails back to January to see what other activity there has been on
> the reporting system, and found some work being done to use jqplot for
> graphs.
> 
> However, it looks like the jqplot patch hasn't yet been fully applied to
> trunk, so I am still seeing the old graphs.  Is this going to be fully
> applied to trunk at some point?  Are there more changes expected so it
> hasn't been applied yet?

There were some minor issues that still needed to be fixed. The contributor of 
the jqplot patch said he is going to look into this, but apparently didn't 
have the time to do so until now. 

> Also, I am finding that the scheme is proving somewhat difficult to sift
> through to locate and/or fix some of the non-compliance issues that
> currently exist. It seems like it would be very helpful to get rid of
> scheme and replace it with something that most people (developers) can
> read and understand easily

I fully agree.

However, the user-visible benefit of replacing the Scheme-based reporting code 
is rather limited. Hence, all talk about this has the fundamental problem of a 
very bad effort - benefit ratio, and that is also why nothing has happened in 
this respect so far.

Having said that, we are at a better situation right now, compared to approx. 
a year ago. Namely, there is a python module inside gnucash which can be 
activated to be loaded at run-time (needs --enable-python and the correct 
installation of the gnucahs python module files). If at all anyone wants to 
make a transition of the reporting code into another scripting language, I 
strongly support python here. Main reasons: We already have wrappers of the 
engine API into python. We also already have the infrastructure to execute 
python code at run-time. And python is clearly more popular, increasing the 
probability that developers can read and understand it.

I don't think any other rewrite of gnucash makes sense as long as you don't 
want to create a completely new application.

> So I am OK with needing to get more familiar with something
> such as Python, C, or Java to do the work, but I don't want to get knee
> deep in a major feature patch to find out something else is preferred.

If you are able to insert some python code that will display some report, I 
will fully agree this to be a worthwhile goal and I will happily apply your 
patches to SVN trunk.

Best Regards,

Christian