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 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel