Report wrapper to call python scripts?

[David Osguthorpe]

On Wed, Dec 24, 2014 at 12:25:23PM +0100, Geert Janssens wrote:
> If I understand you correctly you want to separate the options from the report generating code ? 
> So your wrapper script would be responsible for displaying the options to the user and the 
> actual report script only gets the values passed in ?
> 
> The way I understand the code that will already be a big work because the options for each 
> report are also defined in the same report scheme file. And the whole options handling code is 
> 90% scheme code. The options themselves live in the guile context, not in C. Displaying the 
> options dialog is about 70% guile code which expects the options to live in guile. (I happened to 
> look at that code flow yesterday, that's why I know).
> 

I have been following the various conversations about python - something I am more than interested in.
(I did try to allow python calls from guile using a guile module I found by googling - and returning
data to guile using another such module - but had issues with random crashes so gave that up - the
modules were also not being maintained).

However I then found the python module and used that as the basis so that I now have the ability
to write reports in python 

The only change I made to gnucash was in the python module init script to call another python script
stored in a users .gnucash directory under a python directory - all python and compiled python
modules are stored there (ie no need for distribution in gnucash).

There are 5 compiled modules currently based on pre-gobject introspection codegen (as used for eg pygtk),
pygkeyfile (as apparently there are no distributed GKeyFile python bindings), python bindings
generated by codegen for GncPluginPage (for subclassing in python to create report pages),
GncHtml and GncHtmlWebkit - for final report output. there is also a swighelper python module for
moving objects between python ctypes and swig instances (python ctypes is also used to access some
functionality/data). These are setup for compiling in a gnucash source distribution
- currently in a plugin directory under the python module.

The rest is all python - and yes this does mean I re-implemented options in python - although in a JIT
way so options I have not needed are not implemented. GnuCash objects are accessed using the
distributed python binding classes.
This needs pygtk installed in order to insert into GnuCashs Gtk based GUI - but the python code is
able to install additional menus for the python reports.
(By the way note that GnuCash is multithreaded because Gtk is multi-threaded - in the initial
implementation attempts I had issues with python GIL crashes but these dissappeared when I started
using proper pygobject based implementations of GnuCashs GTypes).

So far I have the basic hello world report in python (with all options implemented that it uses),
cash_flow and a multi-commodity price_scatter (which is what started all this - around gnucash 1.8 I had
a multi-commodity price scatter plot in scheme (the distributed version only did 1 commodity) which
failed (as I know now) when the plotting switched to Javascript based graphs - the python reports are
able to use the Javascript plotting features.

The HTML is generated using the python ElementTree library - all scheme ignored here
although there is a partial implementation of stylesheets
- the access to GncHtmlWebkit is used for the final display of the HTML string.

I have also ignored the KVP code for options - note that options in the python reports do not
apply to the scheme reports - there is no cross-over.

This is all done under OSX (Snow Leopard) using MacPorts as the primary installer of GnuCash,
python 2.7, pygtk etc. - although I have had a small look at working under Linux - my laptop
dual boots OSX/Linux.

The code is in a git repository which can be available if there is interest - although it
contains a lot of history as tried differing approaches.

David