Reporting system

John Ralls jralls at
Thu Jul 7 10:25:09 EDT 2011

On Jul 7, 2011, at 8:25 AM, Christian Stimming wrote:

> 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.

Christian: Please don't accept Python code into Gnucash. Python has version-to-version compatibility problems, and I've found with pure-python applications like Gramps that it requires bundling a Python interpreter with the application so that everyone gets the same version. That 's for Mac, which comes with Python. Windows doesn't, so either the Windows distribution will have to include Python or users will have to download ActiveState's. We already make them download ActiveState Perl if they want Finance::Quote, and have a lot of support issues because of it. Let's not make that worse.

Tim, you realize that in order to rewrite the reports in whatever language you like, you'll have to become quite expert at Scheme anyway, right? You're not going to save yourself any work or learning by translating the reporting system into another language. 

After all of that cold water, I want to emphasize that I do agree with Tim that having the report system in Scheme is a major barrier to users creating their own reports, and I agree that it should be rewritten into a more widely-understood language. That needs to be in an interpreted language so that it remains user-extensible. I think the only viable alternative to Scheme is Javascript, for the following reasons:

* We're already shipping WebKit as part of Gnucash for Windows and Mac, so there's no extra interpreter to include.
* We use HTML to display the reports, and Javascript integrates naturally with CSS and HTML; that's what it's designed for.
* Javascript is widely used by inexperienced programmers who want to juice up a web page, so it's very approachable by users.
* Javascript supports many of the same programming styles that Scheme does, so converting will be straightforward.
* We're already using Javascript to draw the graphs, showing that Javascript can be introduced one report at a time, or even mixed with Scheme, for a gradual migration path.

John Ralls

More information about the gnucash-devel mailing list