[Chart] [GSoC 2013] Progress - Porting Charts to Diagrams

[Tim Docker]

Hi,

On 10/06/13 21:04, Jan Bracker wrote:
> instance ChartBackend CairoBackend where
>   type ChartRenderM CairoBackend = Cairo.Render
>   type ChartOutput CairoBackend = Renderable a -> Int -> Int -> 
> OutputType -> FilePath -> IO ()

I'm not sure we need "Renderable a" here? Renderable is a higher level 
chart library concept that combines a rendering function with a minimum 
bounding box. I don't think the drawing backend should need to know of this?
> For this to work the CRender monad has to be generalized so it can 
> take an inner backend-specific monad as first type parameter.

I am unclear on how this should be structured at this stage... Cairo has 
a monadic interface, based upon IO. diagrams can be created purely (I 
think), however it's not clear if this will still be the case once font 
handling is taken into account.

Rather than have the CRender monad take an extra parameter, I guess one 
could just have a separate data type for each backend (ie CRenderCairo 
and CRenderDiagrams) and have the drawing code abstracted over a 
typeclass implemented by both. Not sure if this would be better...

> While writing this I looked at how Diagrams backend mechanism works. I 
> would like to hear some thoughts on what I did (and in general on my 
> changes so far). I don't really like that there are so many functions 
> in the backend class, but I can't see how to make it smaller without 
> making radical changes to the way that Charts works right now (which 
> Tim and I decided against).

It should actually be possible to trim this down without too much 
effort. There are 8 functions associated with drawing text. It should be 
possible to trim these down to 2 functions (one to get the metrics, and 
one to actually draw it), and then the others could be implemented in 
terms of these.

Tim