Interactive Javascript + Canvas (Flot) powered graphs

[Christian Stimming]

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