Replace XML/SWF Charts with an open system

[dfraser]

XML/SWF Charts:

• has some layout problems on some machines (which are probably fixable)
• is not open source/free software (which is probably not fixable)
• only generates Flash charts (which is a bit icky)

This ticket is to collect the simplest ideas to replace it with something else. Sample options include (please add serious contenders here):

• ​Open Flash Chart - see ​this trac plugin
• ​PlotKit - requires Mochikit, but can generate SVG too - fairly cool
• ​matplotlib
• ​Google Chart API - but that's an external web service dependency

[silk <silk@…>]

Just a comment, why I think Google Chart API would not be a good solution.

For closed source development, sending even the data for graphs to external service may be unacceptable (politicaly, etc). I know it would be a big problem for us.

[dfraser]

Replying to silk <silk@…>:

Just a comment, why I think Google Chart API would not be a good solution.

For closed source development, sending even the data for graphs to external service may be unacceptable (politicaly, etc). I know it would be a big problem for us.

Absolutely, I just included it for reference as it was used by other Trac extensions.

[cboos]

Definitely a must. I would suggest a ​jQuery based solution, like ​Flot.

[mgood]

​jqPlot is another nice jQuery-based library.

[dfraser]

Initial reimplementation of charting in flot

[dfraser]

The attached patch includes the flot.js and excanvas.js files. It seems to work, but not been seriously tested. There's definitely room for work on visuals, but for me it's already nicer than the flash charts :-)

[dfraser]

Screenshot (note that lint and coverage aren't enabled on these tests)

[cmlenz]

​gRaphaël looks pretty darn nice, too.

[Tim Niemueller <tim@…>]

I have packaged Bitten for Fedora and FreeBSD and I'm about to submit these packages for inclusion. For Fedora this is not possible with the given chart library, given that it is not open source and therefore not acceptable as per ​http://fedoraproject.org/wiki/Licensing.

We are not using charting feature in our project, yet. Hence I didn't test the supplied patch. Can someone confirm that the patch is working and a equal replacement?

In that case I'll include the open charting patch in the package and remove the existing stuff. Is there a chance to see this already in 0.6, given that there is a patch available that can do this already?

[anonymous]

Replying to Tim Niemueller <tim@…>:

I have packaged Bitten for Fedora and FreeBSD and I'm about to submit these packages for inclusion. For Fedora this is not possible with the given chart library, given that it is not open source and therefore not acceptable as per ​http://fedoraproject.org/wiki/Licensing.

That's great news...

We are not using charting feature in our project, yet. Hence I didn't test the supplied patch. Can someone confirm that the patch is working and a equal replacement?

The patch is working but is not yet an equal placement - the charts it generates are functional but fairly ugly.

In that case I'll include the open charting patch in the package and remove the existing stuff. Is there a chance to see this already in 0.6, given that there is a patch available that can do this already?

Given this was a first stab and 0.6 is a desparate-release-because-none-has-been-made for ages, it was meant to be deferred... you could bring up a discussion on IRC/the mailing list if you want

[dfraser]

Replying to anonymous:

Replying to Tim Niemueller <tim@…>:

We are not using charting feature in our project, yet. Hence I didn't test the supplied patch. Can someone confirm that the patch is working and a equal replacement?

The patch is working but is not yet an equal placement - the charts it generates are functional but fairly ugly.

Forgot to login - that comment was from me (dfraser)

[Tim Niemueller <tim@…>]

Are you working on this atm? Is it feature-wise equali with the flash charts despite looking ugly? What has to be done otherwise? Would you say it is an acceptable compromise to use your patch and getting it packaged and included in Fedora? Otherwise that would have to wait for some time...

[dfraser]

Replying to Tim Niemueller <tim@…>:

Are you working on this atm? Is it feature-wise equali with the flash charts despite looking ugly? What has to be done otherwise? Would you say it is an acceptable compromise to use your patch and getting it packaged and included in Fedora? Otherwise that would have to wait for some time...

I generated the initial patch, and since the plan was for it to be deferred to 0.7 I haven't put any more effort into it. But I am running a production server using it (on Fedora 7, I produce my own rpms) - the plan is for either this patch or an equivalent patch using an alternative graphing system to make it into bitten for the next milestone, so I think per Fedora's policies it would be best to include it (the only alternative being to remove charting). But I think you should test yourself and see since you're the one who's going to submit it.

[hodgestar]

Updated patched (use either json or simplejson, move legend, remove old charting templates, remove non-functional xaxis ticks).

[hodgestar]

Screenshot of old XML charts for comparison.

[hodgestar]

Screenshot of new JQuery charts (made using patch 2).

[dfraser]

Reworked patch to apply to latest trunk

[dfraser]

The attached patch seems OK to me now - we could potentially do some stylistic adjustments, but as far as I'm concerned, this is at least ready for trunk

[dfraser]

Committed in r846, but leaving this open for testing...

[dfraser]

Backported in [846]; as of that point trunk and 0.6.x are identical except for versioning...

[anatoly techtonik <techtonik@…>]

jQuery sparkline is another library to consider for inline charts ​http://omnipotent.net/jquery.sparkline/

[dfraser]

​Discussion in mailing list on the added requirement for a JSON parser includes this:

Trac has a JSON encoder on trunk, which handles most simple cases. It is used to serialize e.g. ticket field data for the custom query page. See the bottom of (lines 282 and following):

​http://trac.edgewall.org/browser/trunk/trac/util/presentation.py

The plan is to use that as a fallback for the inbuilt JSON library in Python 2.6

[dfraser]

Replying to dfraser:

​Discussion in mailing list on the added requirement for a JSON parser includes this:

Trac has a JSON encoder on trunk, which handles most simple cases. It is used to serialize e.g. ticket field data for the custom query page. See the bottom of (lines 282 and following):

​http://trac.edgewall.org/browser/trunk/trac/util/presentation.py

The plan is to use that as a fallback for the inbuilt JSON library in Python 2.6

Unfortunately it's only available in Trac 0.12 onwards. Bleaugh

[dfraser]

Committed a version that handles using trac's json method, or if not Python's, or if not, an internal version in [857], and backported it in [858]