Line Graphs and Reports

[Christian Stimming]

Michael T. Garrison Stuber wrote:

>>Since new code has to be written anyway, I'd strongly suggest using the Guppi 
>>core API directly from Gnucash. This would basically mean that the code which 
>>currently accesses the Guppi core API and lies in Guppi's directory 
>>libguppitank/guppi-object-{barchart,pie,scatter}.c would the lie inside 
>>Gnucash's src/gnome/gnc-html-guppi.c or similar. 
> 
> As you mentioned, it is a good idea to maintain some sort of wrapper layer
> between GnuCash and Guppi.  


Right, but we should be more precise about what exactly is wrapped 
before whom. I think it is enough to have the scheme 'wrapper' API in 
src/scm/html-barchart.scm etc., so that the report code won't need to 
change even if the graph implementation changes. Everything else within 
Gnucash might be allowed to change -- that is, both the html code 
generation in src/scm/html-barchart.scm *and* the guppi-calling 
implementation in src/gnome/gnc-html-guppi.c. Both code domains are 
totally under our control. I think that especially between the 
implementation in src/gnome/gnc-html-guppi.c and guppi itself there is 
*no* need for an additional abstraction layer. Even now gnc-html-guppi.c 
already uses some knowledge about the guppi internals, namely, some of 
the Guppi options are used in a version-dependent way.

> the same time, libguppitank already
> provides this.  My inclination is to take the current libguppitank code
> and rename it to avoid conflicts, and move it into the GnuCash branch, and
> then modify it to support line plots, and whatever else in the core Guppi
> API we want to add in the future.  It seems sort of silly to write an
> abstraction layer from scratch, 


Oh, I wouldn't bother too much with moving the existing libguppitank 
code to inside gnucash. The current libguppitank implementation (for 
{bar,pie,scatter}charts) is working, so why should we reinvent the wheel 
here? The line plot issue is a different setting. That's a plot type 
where we have to write code for anyway, so we could write the code 
inside gnucash. I see no problem if gnc-html-guppi.c calls libguppitank 
functions for {bar,pie,scatter}charts and "gnc-guppi" functions (or 
whatever it'll be called) for line plots.

I think gnc-guppi as a prefix would be fine. The way that API can be 
designed could follow the libguppitank implementation. That would result 
  in two files gnc-guppi-object-lineplot.[hc] .

Christian