Report system legacy

Geert Janssens janssens-geert at
Mon Jul 1 03:45:11 EDT 2013

On 30-06-13 10:38, Herbert Thoma wrote:
> Am 29.06.2013 17:38, schrieb Geert Janssens:
>> On 29-06-13 16:52, John Ralls wrote:
> <...>
>> Just for clarity, the definitions of report-template and report are purely in guile code (src/reports/report-system/report.scm).
>> Our c code is totally unaware of this. It just passes around opaque SCM objects. I don't even know where the html page appears
>> in this picture. It's not in this part of the code yet. A "report" in report.scm is defined as a record containing a report-type (which is the guid of a base report template), a report-id (just a number), a structure holding the report options, a reference to the editor widget and some housekeeping flags.
>>> Where I'm going with this is that if a report is if a Report is open it will just sit there until the user tries to reload it
>>> (which would include loading a Book with an open report). If the ReportTemplate is changed, the Report gets re-created based
>>> on the new ReportTemplate, right? If the ReportTemplate is gone, which is currently possible if one deletes a "custom report" in
>>> the dialog box, I would hope that Gnucash displays a nice "Can't find the Report" in the HTML page rather than crashing.
>> This doesn't happen, because the custom report's template id is never stored in a report record. Instead the base template on
>> which the custom report template is based on is stored in the report record. So when you reopen a report (by reopening a book),
>> the report currently doesn't even know it ever was instantiated from a custom report. It will reinstantiate from the base template.
>> I believe this was originally done exactly to prevent unexpected crashes when the custom template got deleted.
>> This results in a two-level template hierarchy. The base templates are all the report definitions that ship with gnucash, or that
>> a user loads manually (what I would consider a true "custom report"). What is called custom reports now are the reports a user can
>> save from within the program. Which really aren't much more than a reference to a base report and a custom set of default options.
>> The code keeps this hierarchy shallow. There will never be a custom template based on another custom template. Which I think is
>> good exactly to avoid the template is deleted issue.
>> But I needed to keep track of which custom template a report is instantiated from, so I have now added an extra parameter in the
>> report record to keep track of which custom report was optionally instantiated when the report was generated. I'm still keeping
>> this parameter separately from the "report-type" which will always hold the core template to prevent the crashes you describe.
> My question here is: Why do we need an intermediate custom template at all?
It wasn't needed until now.

This is what has changed: the new user interaction will allow you to do 
this sequence:
- open a report based on a custom template
- make some changes in the options
- hit save -> this will update the custom template the report was based on

For this last step, you need to keep track of which custom template (if 
any) a report is based on.
> If a custom report template is a core template with a set of options, a new custom template
> should be a core template with a set of options as well.
It is.
>   Why do we need the reference to the old
> custom template for the new custom template? What am I missing?
See above.
>   Do changes of options in
> the parent custom template affect the child custom template? If yes, how can a user see such
> dependencies? Would we even want such a behaviour?
Custom templates are never based on other custom templates. Only a 
report can be instantiated from a custom template. So there is no custom 
template hierarchy. As for instantiated reports (or "open" reports if 
you like), they won't change if their custom template changes. A custom 
template is only relevant to open a fresh report based on it. At that 
point all options are copied from the template to the new report. Any 
changes later on in the custom template will not be propagated  to 
already open reports.
> BTW: The whole report logic is too much on the scheme side, IMHO. A while back I tried to
> implement a "refresh all reports" feature (I have a number of reports open and right now the most
> convenient way to refresh them all is to close GnuCash and start it up again ...). I gave up
> on the "refresh all reports" feature, because I could not even find the proper place for the
> for all open reports loop. I could not find a list of open reports in the C side code so I
> concluded it must be on the Scheme side, but my scheme-foo was to low :-(
I agree. The report system is almost purely written in scheme. The only 
parts that touch C are the parts that integrate the whole report logic 
into the GUI.

Unfortunately that's how it is currently. I would take way more time 
than I have available in the short term to change this, though it is one 
of my long term ideas.


More information about the gnucash-devel mailing list