Report wrapper to call python scripts?

Sat Jan 3 05:44:36 EST 2015

Hello,

Having read this thread I wondered if there could be some sort
of interface to export data from gnucash so that any kind of
external report generator could work on it.
Exporting the selected data to i.e. an xml file.
The external program would then handle the data it's way and could
be distributed separately.

To ease such process something like a plugin-system for gnucash
could be introduced.
Having the option to insert a button to start this program or
preferences dialog in the gui.

regards,

Christoph Holtermann

Am 24.12.2014 um 12:25 schrieb Geert Janssens:
> On Wednesday 24 December 2014 12:22:46 Dmitry Pavlov wrote:
>> A brief search through list did not bring any results, so I decided to
>> start a new one.
>>
>> First of all: no offence but most gnucash reports are poorly
>> implemented. It's not because they useless or looks not pretty (most
>> of them are useful and good, calm down :)).
> The report system is indeed in dire need of some attention.
>
>> The reason is that a
>> model (i.e. data of the report) is completely messed up with the view
>> (html tags) in report generation code + html creation tag by tag is
>> really outdated now, there are more proper tools like templates for
>> that.
>>
> Absolutely. That's why a couple of years back one developer started to rewrite the reports 
> based on eguile which is a templating system written in guile.
>
> The developer ran out of time so only a few reports have been written based on eguile: there is 
> a balance sheet and a tax invoice report. And I have just recently added a payment receipt 
> report based on eguile as well.
>
>> Of course it's a really huge work to rewrite that completely in more
>> model-view style or rewrite that in different language.
>>
> Yes. That's one reason it hasn't happened yet.
>
> Other reasons are that the active developers are mostly focused on the core rewrite in c++ 
> making the core a moving target. That's probably not the best moment to rewrite a report 
> system. The current report system - while very outdated - is rather stable and well understood. 
> That makes it easier to keep working on top of a heavily changing core.
>
> Yet another reason why I personally have been holding off of rewriting the report system (other 
> than insufficient time) is that the developers intend to move towards a more sql driven data 
> model. If that succeeds the report system could perhaps be replaced with one of the many 
> existing sql based reporting systems.
>
>> So I have idea: Gnucash already have an infrustructure of invoking
>> scheme reports, saving settings, etc.
>> What about implementing some "wrapper" report that can just invoke
>> some script (for example that use python bindings).
> That could be an interesting approach. However it's important to keep in mind that gnucash 
> supports multiple platforms: linux, Windows and OS X. If you want to write reports intended to 
> be included with gnucash and in a language other than guile that should be a language that is 
> supported on all three platforms.
>
> You mention python. While there are versions of python for all of them, there are no python 
> bindings for gnucash on Windows and OS X. There have been several attempts to get it to work 
> on Windows, but no success just yet. The same goes for OS X. There is no reliable way yet to 
> install working python bindings on all supported versions of OS X. This is mostly due python's 
> own incompatibilities between python versions.
>
> Next if at some point the python bindings are working on all platforms, there is the distribution 
> issue: if we start to depend on python for some features, we would need to ship python with our 
> Windows installer. That would mean a considerable increase in size. That is only justified if the 
> functionality would be greatly enhanced by this.
>
> So as things *currently* stand python is IMO not an option (yet) to replace the reporting system. 
> Sorry about that.
>
> The only languages we have natively available on all supported platforms are c, c++, guile and 
> javascript (via webkit). For guile there are bindings to many of the c libraries. For javascript 
> there aren't (yet?).
>
>> In it's settings
>> we can point to specific script and all guile invocation would just
>> 1. include execution of that script with passing parameters from
>> options
> 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).
>
> So making this part language agnostic means rewriting the options code. Which happens to be 
> something I *am* considering if I find the time :)
>
>> 2. grab output that is supposed to be report content (html
>> for now) and include that as it's own result
>>
> If I understand things correctly this second part is what is done now already. The guile reports 
> generate an html output file that is then parsed by the integrated webkit engine.
>
>> In that case we can have one more language to implement reports,
>> because scheme is not so popular now, and many people find it not so
>> easy to use, especially when we are talking about reporting :)
>>
> As far as I know scheme is indeed not the favorite language of any of the active developers. 
> GnuCash however still greatly depends on it for much of its critical code. It is on the roadmap to 
> change this. That is a big work and help would be much appreciated.
>
> The work is done bottom-up so far: first the core libraries are being revisited and rewritten in 
> c++. That should give us a much better object model to work from for the higher level parts like 
> the gui and reports.
>
>> I'm not sure that I can implement all that stuff myself, but if
>> someone find that idea good enough I'll be glad to discuss that and
>> collaborate to implement that wrapper script.
> I am open to viable alternatives. If you want to pursue the python road the first step would be 
> to make sure the python bindings work reliably on Windows and OS X.
>
> Without that the wrapper script will have to remain in the optional python bindings section of 
> gnucash, greatly reducing its usefulness.
>
> Geert
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B