I don't know how it fits into this rework, but I would like to see a more
general framework which supports reports with 'items' down the side and
'periods' across the top. I put them in quotes because they are a bit
general. I've worked with an accounting system in the past which allowed
general reports to be created. In this case, 'items' could be text strings
(e.g. 'Income'), could be a filter for accounts (all accounts of type
'Income'), could be a total or subtotal row ('Total income'). Across the
top, for 'periods', you could have real periods for an income statement or
comparative income statement, or dates, for a balance sheet or comparative
balance sheet. When I used quicken in the past, I liked being able to
generate a balance sheet for 2015-2018 with all years' values at Jan 1.
This allowed me to see how values had grown or decreased in certain
accounts.On Thu, Jun 7, 2018 at 4:22 PM, John Ralls <jra...@ceridwen.us> wrote: > > > > On Jun 7, 2018, at 1:14 PM, John Ralls <jra...@ceridwen.us> wrote: > > > > > > > >> On Jun 7, 2018, at 12:49 PM, Carsten Rinke <carsten.ri...@gmx.de> > wrote: > >> > >> Hi, > >> > >> this takes up a discussion with John and Christopher in PR#360 (and I > am happy to see that is was merged :-D ) > >> > >> As the discussion turned away from the actual proposal of a test for > the report definition, I'd suggest to move it to this channel. > >> > >> John: > >> You were mentioning that you and Christopher are reworking the report > system. > >> I had in mind to create even more PRs with test proposals for the > report system (in response to Bug787401 which becomes a bit difficult now > that the bug is closed ;-) ) and I wonder: > >> Is this idea still worth while? > >> Do you already have an idea about what is going to change? > >> > >> Christopher: > >> Regarding your question below: > >> I think the report definition is triggered at the very beginning when > the moduels are loaded. > >> inner_main triggers libgncmod_report_gnome_gnc_module_init > (gncmod-report-gnome.c) > >> this triggers to load guile module "gnucash report standard-reports" > (standard-report.scm) > >> this triggers to load all standard reports > >> this triggers that (gnc:define-report) is called per report > >> -> it has nothing to do with html rendering > >> > >> If you take the changes from PR#360 and comment out the report ID in > the call to gnc:define-report from any standard report, you will see that > an "ordinary" pop-up window is created. > >> > >> -Carsten > >> > >> > >> > >> -------- Weitergeleitete Nachricht -------- > >> Betreff: Re: [Gnucash/gnucash] Bug787401 test report definition > (#360) > >> Datum: Thu, 07 Jun 2018 03:47:52 -0700 > >> Von: Christopher Lam <notificati...@github.com> > >> Antwort an: Gnucash/gnucash <reply+026075fc968723c48c7d3e323241b3 > 3bf8470a850e163f0c92cf000000011730cf5892a169ce13999...@reply.github.com> > >> An: Gnucash/gnucash <gnuc...@noreply.github.com> > >> Kopie (CC): GnuFiBux <carsten.ri...@gmx.de>, Author < > aut...@noreply.github.com> > >> > >> > >> > >> I can understand the need to remove gui calls but not entirely sure > exactly how the |(gnc:define-report)| is being called. I know they're being > triggered with every report code e.g. at the end of transaction.scm, but > not sure what exactly is causing the transaction.scm to be run. So, where > will the gui error message be stated? As a html report perhaps? > > > > Carsten, > > > > You don't need a bug report to submit a PR. If you're motivated to keep > adding tests for the report system by all means do! > > > > As to what will change, Geert and I have discussed some general > directions and Chris has been working away at some things that interest > him, see [1]. > > > > We'd like to better separate the data retrieval and summarization from > the presentation, perhaps with an intermediate format. We'd also like to be > able to use something lighter and more portable than WebKitGtk for > in-program report presentation and to support report file output in formats > other than HTML and whatever WebKitGtk lets us print (that's how the PDFs > are created and explains why pagination is a problem: HTML doesn't know > about pagination). > > > > Carsten, > > Some more general issues: > > There is a *lot* of duplicate code in the standard reports that needs to > be extracted into common support code. > > We'd like to make it easier for users to generate custom reports. Having > to learn to program in Scheme sets the bar *way* too high for most users. > Ideally we'd have a Query-by-example UI similar to Microsoft Access or the > old Borland Paradox for data selection and > simple selections for summarization and styling. The results could be > stored in some form that's easily human-editable and machine readable like > YAML, INI, or XML. > > 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
