Scripting

[Andrew Ruthven]

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.

Cheers!

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 gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 

-- 
Andrew Ruthven
Wellington, New Zealand
At home: andrew at etc.gen.nz |      linux.conf.au 2012 
                           | Come with us, Under the Stars
                           | http://lcaunderthestars.org.au
-------------- 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: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20111112/7de7fcc4/attachment-0001.sig>