Interactive Javascript + Canvas (Flot) powered graphs

[Geert Janssens]

On Friday 21 January 2011, Christian Stimming wrote:
> Zitat von Andy Clayton <q3aiml at gmail.com>:
> > I've been playing around with using Flot
> > (http://code.google.com/p/flot/) to replace the goffice report
> > graphs, and it seems to work well. It (re?)introduces interactivity
> > and overall looks much more modern. It's rather clean too, as the
> > existing guile modules are simply changed to output the relevant
> > javascript instead of the <object> tag.
> 
> I think that's a great idea! Moving the code for interactivity
> directly into the HTML/javascript engine IMHO is a much more suitable
> approach than what we previous had with plenty of inter-language
> callbacks (from C to scheme to HTML back to C and to scheme again).
> 
> > * Would such an approach be considered for inclusion in trunk? If
> > so, then I'll cleanup my patches and post/attach to a bug for
> > comments. Or would a different approach be preferred?
> 
> I do consider this for inclusion in trunk immediately.
> 
> > * Assuming inclusion would there be support for dropping goffice and
> > gtkhtml? Remember this would be trunk/2.6, not 2.4.x.
> 
> Yes, as soon as this feature is up and running (i.e. the previous
> charting functions are available in the new code and there is no major
> regression), I support dropping goffice and gtkhtml altogether, rather
> soon. This will for sure mean we will branch off a 2.4 stable branch
> that doesn't have this feature (or not yet activated) and will stick
> to the existing webkit or gtkhtml implementation. Your feature will
> then be available in trunk, but that's what trunk is for.
> 
> > While it would be easy enough to have the guile modules switch
> > between their current output and the JS output depending on if
> > webkit is enabled, I'm not sure that is the best choice. The biggest
> > reason I see for removing them is to keep a more cohesive product.
> > It avoids issues where users need to wonder "Do I have the gnucash
> > with the new graphs?" or "Why does this review/tutorial/blog's
> > gnucash have sexy graphs while mine are blah?". In addition dropping
> > unnecessary dependencies and code, thereby lowering maintenance and
> > duplicated development effort, always seems like a good thing.
> 
> Both are completely valid points and as I said IMHO there is enough
> benefit for us so that I support dropping gtkhtml/goffice completely
> in trunk. (AFTER the new code is able to provide similar chart display
> features, that is.)
> 
> Different from John's idea about additionally dropping scheme, I think
> your proposal doesn't touch the report creation code, which is where
> we are using the majority of scheme code. So your proposal doesn't
> touch the scheme question anyway. Your code will be changing the
> presentation of the (chart) reports, but the generation of the numbers
> that are shown in the reports is a different matter and will continue
> to be done in scheme. This may not be the best solution, but changing
> that to a different platform (python, javascript, ruby etc) firstly
> requires suitable wrappers of the gnucash engine for that language,
> which we have for scheme and partly for python but surely not for
> javascript.
> 
> I'm looking forward to your contributions! (As usual, the best place
> for patches is bugzilla with maybe an additional email here.)
> 
> Best Regards,
> 
> Christian
> 

Totally agreed. This looks like a splendid idea, and I agree also on your and 
Christian's thoughts about how and when.

Geert