[GNC-dev] Report System Rework

Christopher Lam christopher.lck at gmail.com
Sun Jun 10 11:16:17 EDT 2018


Any rework will require stabilising the reports first, removing
unintelligible hacks, and updating to modern scheme (which is now
approaching V8 quality and speed). The current state of report code
reflects the tooling available about 20 years ago.

So the following will be on the TODO list before any foundation changes:

1. creating good tests for majority of reports
2. removing hacks and shortcuts, debugging opportunistically
3. obsoleting old reports (such as eguile <g>)
4. modernising stylesheets (removing/merging plain/header+footer/etc)?
5. designing more modern access to data, either yaml/json/REST

For now the reports will necessarily be limited in interactivity; Input via
Report Options, and Output via HTML. Anything else is for now just a pipe
dream!

On 8 June 2018 at 04:42, Phil Longstaff <phil.longstaff at gmail.com> wrote:

> 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 <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>
> > 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 <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 [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 at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


More information about the gnucash-devel mailing list