On Friday 21 January 2011, Christian Stimming wrote: > 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 >
Totally agreed. This looks like a splendid idea, and I agree also on your and Christian's thoughts about how and when. Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
