Zitat von Andy Clayton <q3a...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
