Sounds like an interesting experiment. One current problem with webkit is that the win32 build environment for the windows build doesn't easily support getting newer versions of webkit/gtk as they are developed. We currently use a build of webkit 1.1.90 and are stuck with this. I am looking for a way to update to a newer version but am running into dependency hell. This problem must be solved because this is also what is keeping us with a really old version of gtk.
Phil --------- I used to be a hypochondriac AND a kleptomaniac. So I took something for it. ________________________________ From: John Ralls <jra...@ceridwen.us> To: Andy Clayton <q3a...@gmail.com> Cc: gnucash-devel@gnucash.org Sent: Thu, January 20, 2011 11:16:19 PM Subject: Re: Interactive Javascript + Canvas (Flot) powered graphs On Jan 20, 2011, at 4:56 PM, Andy Clayton wrote: > Hi all, > > 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. So two questions: > > * 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? > > * Assuming inclusion would there be support for dropping goffice and gtkhtml? >Remember this would be trunk/2.6, not 2.4.x. 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. ISTM that it would make more sense to not have the scheme (guile) intermediation and to do everything in javascript. Otherwise, +1. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
