Hello, using python and jinjaII templating as I tried for invoices could be an interesting thing (just for linux).
For reports SciPy would also be tempting. regards, Christoph Holtermann Am 24.12.2014 um 12:49 schrieb Dmitry Pavlov: > Geert, thank you for a very detailed comments. > > I did't know that situation with python bindings is so complicated on > Windows and OSX, and that can be a real show stopper. > > For the details of implementations my idea was slightly different: options > can be preserved for guile, as options definitions is really the simplest > part of any current report. The python part was planned to only include > report generation and guille part should just pass options to that script, > maybe as command line options or file with that parameters (exact way is > implemtation details, really). > > While I was working on budget report enhancement I've looked at eguile > reports: > 1. they are still using scheme to implement report logic, and changes can > be painfull :) > 2. template part is full of small scriptlets (scheme code insertions) and > at least it's worth to make some taglib (sorry for that java world term) so > that common formatting and type conversion failures can be hidden for > template authors by simple formatting constructs. > > It seems that until python problems can't be solved such report > implementation can only be a local linux version feature, not included in > distro. Anyway if some linux user/developer want to participate, I'm ready > :). > > As for more global change, personally me not sure to find enough time and > scheme knowledge to rewrite many reports at least to eguile, but if I'll > manage to find time, I'll let you know. > > Thank you all for comments! > > > 2014-12-24 14:25 GMT+03:00 Geert Janssens <geert.gnuc...@kobaltwit.be>: > >> 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 >> > > -- --- 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
