Reporting system
Hi, As you know I have done a little work on the reporting system to try to get some form of standards-compliance working. I have been looking through previous mails back to January to see what other activity there has been on the reporting system, and found some work being done to use jqplot for graphs. However, it looks like the jqplot patch hasn't yet been fully applied to trunk, so I am still seeing the old graphs. Is this going to be fully applied to trunk at some point? Are there more changes expected so it hasn't been applied yet? Also, I am finding that the scheme is proving somewhat difficult to sift through to locate and/or fix some of the non-compliance issues that currently exist. It seems like it would be very helpful to get rid of scheme and replace it with something that most people (developers) can read and understand easily, and also rewritten to make new reports much easier to create. Based on what I've read in the mailing list history it sounds like scheme is desired to be removed anyways, but I am wondering if there is any consensus on what it should be replaced by? I may or may not be capable of doing this, I will have to try and see but I am finding that additional work on standards compliance will pretty much mean replacing the scheme code. Fixing the scheme would be possible of course, but it doesn't seem worthwhile if it will be a lot of work and then replaced by something else anyways. Given the drastic need of an overhaul for the reporting system (IMO), it seems reasonable to just blow it up and start working on a new and improved reporting system. I am wondering if this should also be part of the larger discussion I have seen going on regarding moving Gnucash in general perhaps to another language such as Java (or redoing it in Objective C). Basically I just want to know in advance if I am going to do any work on the reporting system, what should I use to rewrite the code? I am becoming very comfortable with ruby but that would require another dependency I suppose (i saw someone mention it so I thought i'd throw it out there). I have experience with a swath of scripting languages and limited Java and C++ experience. So I am OK with needing to get more familiar with something such as Python, C, or Java to do the work, but I don't want to get knee deep in a major feature patch to find out something else is preferred. Thanks, -Tim ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system
Hi Tim, Am Donnerstag, 7. Juli 2011 schrieb Tim M: As you know I have done a little work on the reporting system to try to get some form of standards-compliance working. I have been looking through previous mails back to January to see what other activity there has been on the reporting system, and found some work being done to use jqplot for graphs. However, it looks like the jqplot patch hasn't yet been fully applied to trunk, so I am still seeing the old graphs. Is this going to be fully applied to trunk at some point? Are there more changes expected so it hasn't been applied yet? There were some minor issues that still needed to be fixed. The contributor of the jqplot patch said he is going to look into this, but apparently didn't have the time to do so until now. Also, I am finding that the scheme is proving somewhat difficult to sift through to locate and/or fix some of the non-compliance issues that currently exist. It seems like it would be very helpful to get rid of scheme and replace it with something that most people (developers) can read and understand easily I fully agree. However, the user-visible benefit of replacing the Scheme-based reporting code is rather limited. Hence, all talk about this has the fundamental problem of a very bad effort - benefit ratio, and that is also why nothing has happened in this respect so far. Having said that, we are at a better situation right now, compared to approx. a year ago. Namely, there is a python module inside gnucash which can be activated to be loaded at run-time (needs --enable-python and the correct installation of the gnucahs python module files). If at all anyone wants to make a transition of the reporting code into another scripting language, I strongly support python here. Main reasons: We already have wrappers of the engine API into python. We also already have the infrastructure to execute python code at run-time. And python is clearly more popular, increasing the probability that developers can read and understand it. I don't think any other rewrite of gnucash makes sense as long as you don't want to create a completely new application. So I am OK with needing to get more familiar with something such as Python, C, or Java to do the work, but I don't want to get knee deep in a major feature patch to find out something else is preferred. If you are able to insert some python code that will display some report, I will fully agree this to be a worthwhile goal and I will happily apply your patches to SVN trunk. Best Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system
On Jul 7, 2011, at 8:25 AM, Christian Stimming wrote: Hi Tim, Am Donnerstag, 7. Juli 2011 schrieb Tim M: As you know I have done a little work on the reporting system to try to get some form of standards-compliance working. I have been looking through previous mails back to January to see what other activity there has been on the reporting system, and found some work being done to use jqplot for graphs. However, it looks like the jqplot patch hasn't yet been fully applied to trunk, so I am still seeing the old graphs. Is this going to be fully applied to trunk at some point? Are there more changes expected so it hasn't been applied yet? There were some minor issues that still needed to be fixed. The contributor of the jqplot patch said he is going to look into this, but apparently didn't have the time to do so until now. Also, I am finding that the scheme is proving somewhat difficult to sift through to locate and/or fix some of the non-compliance issues that currently exist. It seems like it would be very helpful to get rid of scheme and replace it with something that most people (developers) can read and understand easily I fully agree. However, the user-visible benefit of replacing the Scheme-based reporting code is rather limited. Hence, all talk about this has the fundamental problem of a very bad effort - benefit ratio, and that is also why nothing has happened in this respect so far. Having said that, we are at a better situation right now, compared to approx. a year ago. Namely, there is a python module inside gnucash which can be activated to be loaded at run-time (needs --enable-python and the correct installation of the gnucahs python module files). If at all anyone wants to make a transition of the reporting code into another scripting language, I strongly support python here. Main reasons: We already have wrappers of the engine API into python. We also already have the infrastructure to execute python code at run-time. And python is clearly more popular, increasing the probability that developers can read and understand it. I don't think any other rewrite of gnucash makes sense as long as you don't want to create a completely new application. So I am OK with needing to get more familiar with something such as Python, C, or Java to do the work, but I don't want to get knee deep in a major feature patch to find out something else is preferred. If you are able to insert some python code that will display some report, I will fully agree this to be a worthwhile goal and I will happily apply your patches to SVN trunk. Christian: Please don't accept Python code into Gnucash. Python has version-to-version compatibility problems, and I've found with pure-python applications like Gramps that it requires bundling a Python interpreter with the application so that everyone gets the same version. That 's for Mac, which comes with Python. Windows doesn't, so either the Windows distribution will have to include Python or users will have to download ActiveState's. We already make them download ActiveState Perl if they want Finance::Quote, and have a lot of support issues because of it. Let's not make that worse. Tim, you realize that in order to rewrite the reports in whatever language you like, you'll have to become quite expert at Scheme anyway, right? You're not going to save yourself any work or learning by translating the reporting system into another language. After all of that cold water, I want to emphasize that I do agree with Tim that having the report system in Scheme is a major barrier to users creating their own reports, and I agree that it should be rewritten into a more widely-understood language. That needs to be in an interpreted language so that it remains user-extensible. I think the only viable alternative to Scheme is Javascript, for the following reasons: * We're already shipping WebKit as part of Gnucash for Windows and Mac, so there's no extra interpreter to include. * We use HTML to display the reports, and Javascript integrates naturally with CSS and HTML; that's what it's designed for. * Javascript is widely used by inexperienced programmers who want to juice up a web page, so it's very approachable by users. * Javascript supports many of the same programming styles that Scheme does, so converting will be straightforward. * We're already using Javascript to draw the graphs, showing that Javascript can be introduced one report at a time, or even mixed with Scheme, for a gradual migration path. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system
On Thu, Jul 7, 2011 at 9:25 AM, John Ralls jra...@ceridwen.us wrote: Christian: Please don't accept Python code into Gnucash. Python has version-to-version compatibility problems, and I've found with pure-python applications like Gramps that it requires bundling a Python interpreter with the application so that everyone gets the same version. That 's for Mac, which comes with Python. Windows doesn't, so either the Windows distribution will have to include Python or users will have to download ActiveState's. We already make them download ActiveState Perl if they want Finance::Quote, and have a lot of support issues because of it. Let's not make that worse. Tim, you realize that in order to rewrite the reports in whatever language you like, you'll have to become quite expert at Scheme anyway, right? You're not going to save yourself any work or learning by translating the reporting system into another language. Yes, I realize that :) But, at least once a rewrite is done it will be much easier to make changes going forward. After all of that cold water, I want to emphasize that I do agree with Tim that having the report system in Scheme is a major barrier to users creating their own reports, and I agree that it should be rewritten into a more widely-understood language. That needs to be in an interpreted language so that it remains user-extensible. I think the only viable alternative to Scheme is Javascript, for the following reasons: * We're already shipping WebKit as part of Gnucash for Windows and Mac, so there's no extra interpreter to include. * We use HTML to display the reports, and Javascript integrates naturally with CSS and HTML; that's what it's designed for. * Javascript is widely used by inexperienced programmers who want to juice up a web page, so it's very approachable by users. * Javascript supports many of the same programming styles that Scheme does, so converting will be straightforward. * We're already using Javascript to draw the graphs, showing that Javascript can be introduced one report at a time, or even mixed with Scheme, for a gradual migration path. I will go with Javascript then. When I have time I will try to come up with a strategy to accomplish this before I start to implement anything, but it may take some time to figure everything out since I will inevitably need to get a bit more familiar with the existing scheme system before I can make significant changes. Thanks, -Tim Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GnuCash - Year End Questions
Hi Several questions 1. Do I have to reconcile? 2. How do I update to the newest version of gnucash without losing my data in this new version? Do I have to do some type of export from old gnu and then import to the new gnu (if so, then how?)? 3. My year end is May 31. How do I close the fiscal year? 4. My year begins on June 1st. How do I start the new year? I am not an accountant, but learning on the fly with the most basic needs. Do you have step by step info (youtube/pdf….) to help me find the info. I seem to be reading up on lots of other info and not finding the right info for me. I hope you can help me. Thank you. cheers, Winslow in Switzerland ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Month- wise reports
How can i get month -wise report of all income and expenses.Now the Cash book shows all tranactions in day- wise format. Thanks, -- narayanan c m ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
Am Donnerstag, 7. Juli 2011 schrieb John Ralls: So I am OK with needing to get more familiar with something such as Python, C, or Java to do the work, but I don't want to get knee deep in a major feature patch to find out something else is preferred. If you are able to insert some python code that will display some report, I will fully agree this to be a worthwhile goal and I will happily apply your patches to SVN trunk. Christian: Please don't accept Python code into Gnucash. Python has version-to-version compatibility problems, and I've found with pure-python applications like Gramps that it requires bundling a Python interpreter with the application so that everyone gets the same version. You do realize that gnucash already comes with a lot of python code for quite some time being, don't you? Namely we already have the python wrappers for the core engine object being generated by SWIG for approx. 2-3 years by now. More recently, there has been an optional python module added so that the framework is already there to do some real new features with that. To me, issues with version incompatibilities in python are indeed a drawback of that language, but all languages have drawbacks and advantages. The clear advantages to allow python code in gnucash is that * the python wrappers for all engine objects are already there, so using them is a rather efficient way of using your time to implement something new * the python language is significantly more easy to learn and suits the normal programmer's thinking much better than other languages As for JavaScript, you have the disadvantage that we (so far) don't have wrappers for all of our engine objects, so this is a very boring task that needs to be begun and somewhat completed first. Also, the JavaScript language is significantly difficult to work with in a serious way. It's much more like Scheme than one would initially expect, and it suffers the same problem than Scheme: Only a smaller set of programmers really understand the concepts behind it well enough to create good architectures in that language. With this being said, we had Tim's question here: I'd like to improve something with the reports; which language should I use. With the above advantages and disadvantages, I still think the most efficient way for Tim to spend his time is creating a report in python. And yes, I still think I will happily add related python code into the optional src/python/ module, even though we know about the limitations of python w.r.t. version issues. But we also know about its benefits. My cost-benefit comparison so far still turns out python as the suggested way to proceed for now. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system
Am Donnerstag, 7. Juli 2011 schrieb Tim M: Tim, you realize that in order to rewrite the reports in whatever language you like, you'll have to become quite expert at Scheme anyway, right? You're not going to save yourself any work or learning by translating the reporting system into another language. Yes, I realize that :) But, at least once a rewrite is done it will be much easier to make changes going forward. I suggest not to try to re-write the existing reports. Indeed this would require to understand the existing Scheme reporting framework. Instead, I suggest to just go ahead and experiment in python to create some HTML output from some calculations as suitable for the intended report output. Eventually, maybe an idea for an alternative python-based reporting framework might evolve. Even more eventually, the gnucash developers will make a decision about whether the old or such an experimental new reporting framework is the more useful one in the long run. Only after that point (i.e. once a new framework has shown its potential value) I would revisit the question of rewriting the old reports into some new framework. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
Hi, No one seems to be intereted in this, but I have pushed some tweakes in build system and push to https://github.com/sss/gnucash-docs/tree/2.4.1-in-epub-and-mobi , and you can downloadn .epub / .mobi from https://github.com/sss/gnucash-docs/downloads . Thanks, -- SASAKI Suguru mailto:sss.so...@gmail.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
build check failure: POTFILES references non-existing gnc-pricedb-static.c?
Hey, I just tried to build a clean build from a clean checkout of trunk on a fresh Fedora-15 system. In addition to two bugs I just filed I also ran into another issue in make check on trunk: make[1]: Entering directory `/home/warlord/src/gnucash/gnucash-svk/build/po' make[1]: *** No rule to make target `../src/engine/gnc-pricedb-static.c', needed by `gnucash.pot'. Stop. make[1]: Leaving directory `/home/warlord/src/gnucash/gnucash-svk/build/po' make: *** [check-recursive] Error 1 I cannot find gnc-pricedb-static.c in the sources, but it does appear to be in POTFILES.in? Was this an oversight? POTFILES.in was last modified on May 31st: r20723: gjanssens | 2011-05-31 09:07:30 -0400 -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Jul 7, 2011, at 4:24 PM, Christian Stimming wrote: Am Donnerstag, 7. Juli 2011 schrieb John Ralls: So I am OK with needing to get more familiar with something such as Python, C, or Java to do the work, but I don't want to get knee deep in a major feature patch to find out something else is preferred. If you are able to insert some python code that will display some report, I will fully agree this to be a worthwhile goal and I will happily apply your patches to SVN trunk. Christian: Please don't accept Python code into Gnucash. Python has version-to-version compatibility problems, and I've found with pure-python applications like Gramps that it requires bundling a Python interpreter with the application so that everyone gets the same version. You do realize that gnucash already comes with a lot of python code for quite some time being, don't you? Namely we already have the python wrappers for the core engine object being generated by SWIG for approx. 2-3 years by now. More recently, there has been an optional python module added so that the framework is already there to do some real new features with that. To me, issues with version incompatibilities in python are indeed a drawback of that language, but all languages have drawbacks and advantages. The clear advantages to allow python code in gnucash is that * the python wrappers for all engine objects are already there, so using them is a rather efficient way of using your time to implement something new * the python language is significantly more easy to learn and suits the normal programmer's thinking much better than other languages As for JavaScript, you have the disadvantage that we (so far) don't have wrappers for all of our engine objects, so this is a very boring task that needs to be begun and somewhat completed first. Also, the JavaScript language is significantly difficult to work with in a serious way. It's much more like Scheme than one would initially expect, and it suffers the same problem than Scheme: Only a smaller set of programmers really understand the concepts behind it well enough to create good architectures in that language. With this being said, we had Tim's question here: I'd like to improve something with the reports; which language should I use. With the above advantages and disadvantages, I still think the most efficient way for Tim to spend his time is creating a report in python. And yes, I still think I will happily add related python code into the optional src/python/ module, even though we know about the limitations of python w.r.t. version issues. But we also know about its benefits. My cost-benefit comparison so far still turns out python as the suggested way to proceed for now. There's a big difference between a toy Python console for hackers and reports at the core of user interaction with Gnucash. Like src/gnc, src/optional.gtkmm, and src/cmakefilemodules, src/optional/python isn't appropriate to include in a general-distrbution binary. The standard reports *must* be included in such a binary. You're right, though, that Javascript is a non-starter. I hadn't adequately investigated what it would take to access the data from javascript. (Details in my reply to Phil.) I think Tim is looking for something different than you think, but I'll let him speak for himself. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
What I'm looking for is this: Separate the act of actually gathering the data from the GnuCash database from transforming it for display, so that the output can be made much more interactive and easy to style and make 'pretty' :). Use a well known programming language to aggregate the data to make it easier to create new reports which output different sets of data. I've thought about this a little bit, and here is what I am thinking. Let me know if this sounds un/reasonable or just plain incorrect. (Note that I am basing this off of not being familiar yet with how the current scheme architecture actually manages pulling the data out of gnucash, so please correct me where I am wrong or point out the significant flaws) 1. Create the 'new' reporting system alongside the existing one so that the reports do not suffer until the existing functionality can be fully replaced by the new system. After all reports are replaced and working, the old scheme code could be pulled. 2. Create a set of libraries and/or use the existing gnucash libraries for querying information from the database. Based on the discussion, I presume C or Objective C would be best and just avoid Python/Scheme altogether (I am not sure how the scheme system actually performs the data queries right now). If all the necessary code is already in place, then this does not require any work. 3. Using these libraries, create the code for aggregating the data (also in C or Objective C) for each report. A single prototype report would be OK to start. Output the report data as structured XML. The XML data should adhere to an XML schema. 4. For each report, create an XSLT file which will transform the data into HTML/XHTML for display. 5. A small amount of javascript would be needed to perform the actual XSLT transformation but it would be pretty small. 6. Style the page elements using CSS. Also, I think the jqplot patch that has been made could be migrated in to the new reporting system, as those graphs look really nice. I think there are several benefits to this approach: 1. Currently reports can only be exported as HTML. By making the reporting code export an XML data structure, reports could be easily exported from GnuCash as XML (pre-transformation) or as HTML (post-transformation). 2. Anyone could write their own XSLT transformation file to display the data differently. 3. The actual XSLT, HTML, and CSS code would be very easy to read and modify by anyone familiar with it. The backend reports would still be in C/Objective C for compiling the data and as such require some coding knowledge, but it would be much easier to start using than the existing scheme code. 4. The XSLT and CSS could be very easily modified and applied not only inside of GnuCash, but a user could also take the XSLT and CSS scripts, modify and apply them to the exported XML reports to give it their own look without touching the GnuCash code base at all. For example they might want to style a report with a company logo or different colors or other graphical elements. 5a. In the future, it would be possible to provide multiple different XSLT and/or CSS styles for the reports so users could select the appearance of the reports. (If someone writes additional styles) 5b. In the future, it would be possible to allow users to import their own style sheets into GnuCash and apply them to the reports. (if someone writes the code to manage the import and style selection) 6. No reliance on Scheme or Python. Minimal Javascript, but that should be handled easily by webkit. Thoughts? -Tim On Thu, Jul 7, 2011 at 4:58 PM, John Ralls jra...@ceridwen.us wrote: On Jul 7, 2011, at 4:24 PM, Christian Stimming wrote: Am Donnerstag, 7. Juli 2011 schrieb John Ralls: So I am OK with needing to get more familiar with something such as Python, C, or Java to do the work, but I don't want to get knee deep in a major feature patch to find out something else is preferred. If you are able to insert some python code that will display some report, I will fully agree this to be a worthwhile goal and I will happily apply your patches to SVN trunk. Christian: Please don't accept Python code into Gnucash. Python has version-to-version compatibility problems, and I've found with pure-python applications like Gramps that it requires bundling a Python interpreter with the application so that everyone gets the same version. You do realize that gnucash already comes with a lot of python code for quite some time being, don't you? Namely we already have the python wrappers for the core engine object being generated by SWIG for approx. 2-3 years by now. More recently, there has been an optional python module added so that the framework is already there to do some real new features with that. To me, issues with version incompatibilities in python are indeed a drawback of that language, but all languages have drawbacks and advantages. The clear
Re: Reporting system and potentially Python
On Jul 7, 2011, at 9:48 PM, Tim M wrote: What I'm looking for is this: Separate the act of actually gathering the data from the GnuCash database from transforming it for display, so that the output can be made much more interactive and easy to style and make 'pretty' :). Use a well known programming language to aggregate the data to make it easier to create new reports which output different sets of data. I've thought about this a little bit, and here is what I am thinking. Let me know if this sounds un/reasonable or just plain incorrect. (Note that I am basing this off of not being familiar yet with how the current scheme architecture actually manages pulling the data out of gnucash, so please correct me where I am wrong or point out the significant flaws) 1. Create the 'new' reporting system alongside the existing one so that the reports do not suffer until the existing functionality can be fully replaced by the new system. After all reports are replaced and working, the old scheme code could be pulled. 2. Create a set of libraries and/or use the existing gnucash libraries for querying information from the database. Based on the discussion, I presume C or Objective C would be best and just avoid Python/Scheme altogether (I am not sure how the scheme system actually performs the data queries right now). If all the necessary code is already in place, then this does not require any work. 3. Using these libraries, create the code for aggregating the data (also in C or Objective C) for each report. A single prototype report would be OK to start. Output the report data as structured XML. The XML data should adhere to an XML schema. 4. For each report, create an XSLT file which will transform the data into HTML/XHTML for display. 5. A small amount of javascript would be needed to perform the actual XSLT transformation but it would be pretty small. 6. Style the page elements using CSS. Also, I think the jqplot patch that has been made could be migrated in to the new reporting system, as those graphs look really nice. I think there are several benefits to this approach: 1. Currently reports can only be exported as HTML. By making the reporting code export an XML data structure, reports could be easily exported from GnuCash as XML (pre-transformation) or as HTML (post-transformation). 2. Anyone could write their own XSLT transformation file to display the data differently. 3. The actual XSLT, HTML, and CSS code would be very easy to read and modify by anyone familiar with it. The backend reports would still be in C/Objective C for compiling the data and as such require some coding knowledge, but it would be much easier to start using than the existing scheme code. 4. The XSLT and CSS could be very easily modified and applied not only inside of GnuCash, but a user could also take the XSLT and CSS scripts, modify and apply them to the exported XML reports to give it their own look without touching the GnuCash code base at all. For example they might want to style a report with a company logo or different colors or other graphical elements. 5a. In the future, it would be possible to provide multiple different XSLT and/or CSS styles for the reports so users could select the appearance of the reports. (If someone writes additional styles) 5b. In the future, it would be possible to allow users to import their own style sheets into GnuCash and apply them to the reports. (if someone writes the code to manage the import and style selection) 6. No reliance on Scheme or Python. Minimal Javascript, but that should be handled easily by webkit. I like the idea of XML output with XSLT to transform it to HTML. That would be a great enhancement. Moving away from a heavy-weight general language like Scheme or Python is the right directin, but switching to C is unfortunately a step backward for custom reports. The current Scheme query interface makes it difficult to write a custom query; a C (or any other compiled language) query would make it impossible for anyone who isn't able to recompile Gnucash. Besides, C isn't really very expressive as a query language. Something SQL-like would be better. A query-by-example GUI would be best. I suppose that could be split off as a separate project, though, so that the Scheme query capability would remain for custom reports while the standard reports have their queries written in C. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On 2011-07-07, at 21:48, Tim M wrote: […] Thoughts? I like the idea of XML - HTML + CSS + JavaScript plots. How about moving to a completely declarative XML report, where we use XML tags to ask for things like account names and balances, and using the Scheme (or Python) reporting engine to replace the XML tags with actual values? That way, you can have something like: report titleIncome Statement/title subtitle start_date/ to end_date/ /subtitle filter type=“date” fromstart_date//from toend_date//to tabular account_group name=“income”/ account_group name=“expenses”/ account title=“Net Profit (Loss)” add account_group_balance name=“income”/ account_group_balance name=“expenses”/ /add /account /tabular /filter type=“date” /report So people can be given a set of XML reporting ‘primitives’, and combine them in different ways to write different reports. My 2c, Yawar PGP.sig Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
