Interactive Javascript + Canvas (Flot) powered graphs

[Phil Longstaff]

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 <jralls at ceridwen.us>
To: Andy Clayton <q3aiml at gmail.com>
Cc: gnucash-devel at 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 at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel