Report wrapper to call python scripts?
zeldigas at gmail.com
Wed Dec 24 11:07:45 EST 2014
Can you send link to your git repo with that changes?
24 дек. 2014 г. 18:39 пользователь "David Osguthorpe" <
david.osguthorpe at gmail.com> написал:
> 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
> - 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
> graphs - the python reports are
> 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
> 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.
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel