reports & html status

[Robert Graham Merkel]

<note: cc'ing to -devel, you sent a virtually identical mail there>

Bill Gribble writes:

 > We are at the time when I need to send you a patch.  The deal is that
 > I'm depending on CVS releases of guppi, glibwww2, and gtkhtml, plus
 > non-CVS patches to gtkhtml.  I will put one together this afternoon.
 > 
OK.  
 > Anyway, I am still using all the old code for representing and
 > generating report HTML, with the minor exception that I added about 20
 > lines of guile code to put an options object, report-type identifier,
 > and a cache of report output (unused ATM) in an "instantiated report"
 > (<inst-report>) record and made a global hash of
 > 'inst-report-identifiers' (just increasing ints) to <inst-reports> so
 > my report URLs look like href="gnc-report:id=26", where 26 is the hash
 > index of the instantiated report (unique per session but not saved).
 > This will probably have to change; I think we'll need to save/restore
 > <inst-report> objects or whatever they're replaced with across
 > sessions (so the main window shows the same reports w/same parameters
 > after a quit/restart).
 > 
Yep.  I've already been thinking about
 > What I'm looking for from you: 
 > 
 > (1) tell me what you need from me to move forward with the paned main
 > window.  I mean in the sense of putting reports in it, etc.  ATM the
 > report window always has its own top-level window but I can easily
 > change that.
 > 
I need an interface that lets me create a reportwindow, stuff a report
into it, delete it, set the report options, and pass in a popup menu.
In the interface to the virtualised mainwindow-account-tree widget, I
pass in a GnomeUIInfo *, have you done something else?

 > (2) I am hoping that you have made some headway on the html-generation
 > problem so that we can replace the current generator-thunk system with
 > something new and better.  Now that we need to generate graph-defining
 > HTML it's more important to have something reasonable in the way of 
 > an interface. 
 > 
My current plans are essentially to largely borrow some of g-wrap's
string generation code, which has a very template-replacement like
feel, and then use that to build a table generator.  The frippery
around the edges would essentially be done with template replacement,
but the table would be done in a programmatic way.

 > (3) I have started on a 'reporting analysis' library.  I'm working on
 > the assumption that reports are essentially just 4 things: a Query, an
 > algorithm, some parameters, and a display formatter.  this should make
 > reports run faster and be easier to write.  I want to talk to you
 > about what the interface mechanics should be to make it work smoothly
 > with the new report objects.
 > 
OK, if you want to do that, how about talking the biggest, nastiest
'reporting analysis' question - calculating Return On Investment (ROI)
in shares and mutual funds. . . 

 > (4) we have to start making some new reports.  Do you have any
 > thoughts about how we go about making them nice looking?  How can I
 > figure out what gtkhtml supports in the way of style sheets etc?
 > 
We can insist that all the reports use styles specified in a style
sheet, and perhaps generate that style sheet on the fly based on
global/local options.  That could perhaps be provided as a
"generate-header" function.  I don't know exactly what style sheets gtkhtml
supports.


------------------------------------------------------------
Robert Merkel	                           rgmerk@mira.net

"We are excited and optimistic about its usage going 
forward and, yes, we can teach penguins the military 
close-order drill", Mark Norton, US Department of Defense. 
------------------------------------------------------------