[GNC-dev] Report System Rework
phil.longstaff at gmail.com
Thu Jun 7 16:42:22 EDT 2018
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
On Thu, Jun 7, 2018 at 4:22 PM, John Ralls <jralls at ceridwen.us> wrote:
> > On Jun 7, 2018, at 1:14 PM, John Ralls <jralls at ceridwen.us> wrote:
> >> On Jun 7, 2018, at 12:49 PM, Carsten Rinke <carsten.rinke at gmx.de>
> >> 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
> >> 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
> >> this triggers to load guile module "gnucash report standard-reports"
> >> 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
> >> Datum: Thu, 07 Jun 2018 03:47:52 -0700
> >> Von: Christopher Lam <notifications at github.com>
> >> Antwort an: Gnucash/gnucash <reply+026075fc968723c48c7d3e323241b3
> 3bf8470a850e163f0c92cf000000011730cf5892a169ce139994a3 at reply.github.com>
> >> An: Gnucash/gnucash <gnucash at noreply.github.com>
> >> Kopie (CC): GnuFiBux <carsten.rinke at gmx.de>, Author <
> author at 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 .
> > 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).
> 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.
> John Ralls
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel