Andrew Ruthven andrew at
Sat Nov 12 05:33:50 EST 2011

Hi Hendrik,

I've felt your pain.  The reasonably new python bindings are pretty
helpful.  The documentation is still somewhat lacking, but there are
some examples, and with a bit of digging through the doxygen output (and
in some cases the .h and .c files) I've been able to work out how to do
what want.


On Fri, 2011-11-11 at 20:40 +0000, Hendrik Boom wrote:
> A few years ago I wanted some printouts of gnucash data formatted in a 
> form that my wife and I could use.  It was frustrating to me that the 
> easiest way to accomplish that was to reverse-engineer the gnucash file 
> and hand-coding a C++ program that read in the XML file and further 
> processed it.  The initial, usable, form of this program was written in C+
> + in about a day.  Over the years, I've embellished it in various ways, 
> sometimes to change functionality, sometimes to accomodate subtle changes 
> in the gnucash file format.
> But it seems silly to duplicate stuff that's probably in gnucash itself, 
> and is even maintained by the gnucash implementers.  And it's obvious 
> that with the shift to a database, I should consider reading the database 
> instead of the (probably derivative and deprecated) XML file.
> I had looked at the gnucash source code, but I found it much harder to 
> understand than the XML file itself.  I had asked for information about 
> an API for understanding the internal gnucash state and was referred to 
> some (IIRC machine-generated) documentation.  It didn't help much 
> either.  In particular, it didn't make it clear what I had to do to set 
> up the internal gnucash state that it was reporting on.  While a fine API 
> for code that ws embedded within gnucash, it didn't really suffice for  
> external code.
> And looking at the guile interface for reports didn't help much  either, 
> even though I was an experienced Lisp/Scheme programmer.  At the time (is 
> this still the case?) the only usable documentation to the reporting 
> subsystem was the source code for the reports themselves.  This 
> definitely wasn't enough.  The report code was full of functions with 
> obscure names and equally obscure significance.
>   This isn't a problem with Scheme being a difficult language to learn.  
> It isn't difficult.  It can be learned by a competent programmer in a day 
> or two.  It's a problem with obscurity of the API the reporting subsystem 
> provides to the Scheme programmer.
> In subsequent years I've wanted to produce report output in forms other 
> than HTML, which, as far as I know, is the only one supported by gnucash.
> I've also wanted to write some custom data-entry software for getting 
> data into gnucash.
> Now presumably, given enough time, I'd have been able to overcome these 
> obstacles to interfacing with gnucash code the way it obviously wants to 
> be used.  But, of course, at the moments I was faced with the need to 
> produce, there wasn't enough time.
> ***
> Now I'm not really interested in just complaining.  If you'll forgive a 
> lurker, but long-time user, from speaking up, let me at least make a 
> proposal.  Yes, I know it will probably be a lot of work, and who will be 
> found to do it, etc.  What I'd like to hear is whether there are serious 
> flaws here, and whether it's ever likely to gain the social support to 
> make it worthwhile to try, etc.
> (1) The bulk of the code for gnucash should be a shared library, whose API
> (s) provide all the essential functionality of gnucash.  This would 
> include code for starting up gnucash, shutting it down, reading gnucash 
> fies, opeining the usual gnucash window, and so forth.  The current work 
> of converting ad-hoc code to use Gobjects could go a long way to making 
> this API consistent. 
> (2) The gnucash main program itself should operate entirely by using this 
> library's API.
> Maybe (1) and (2) is how gnucash is already structured; I don't know.
> (3) This library would be the basis for scripting interfaces to gnucash.  
> The API would make the gnucash library itself indifferent to the 
> scripting language being used.  Of course, the API must still be clearly 
> documented, or it will be practically useless.  Documentation in the 
> header files may suffice.
> ----
> It's worth noting here that some systems that can be used as scripting 
> languages are capable of handling the C and C++ interfacing on their own, 
> requiring no significant footprint in the gnucash library itself.  (I'm 
> thinking specifically  about Gambit C here, which is an implementation of 
> Scheme taht can compile to C.  No doubt there are others.)
> Other languages that different users might want to use on top of gnucash? 
> JavaScript, Python, Ruby and Erlang have been mentioned as languages that 
> are in the Lisp camp as far as semantics goes.  Several of them are 
> interpreted.  Google has recently put out a language that's designed for 
> programs that partly run on a server and partly on a browser.  Accessing 
> gnucash from a browser, even only read-only, could be useful.
> But now I'm getting far in advance of myself.  I'm currently arguing only 
> for a clear, conprehensive, documented API that others could use to build 
> their own edifices on top of gnucash.  That would open the gates to all 
> kinds of unexpected collaborations.
> -- hendrik
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

Andrew Ruthven
Wellington, New Zealand
At home: andrew at | 2012 
                           | Come with us, Under the Stars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the gnucash-devel mailing list