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

[Jan Bracker]

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?


I tried to implement a few things based on my approach and you are
absolutly right it is not necessary.

 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...


Still types like "CRenderCairo" and "CRenderDiagrams" have to be Monads,
because otherwise we would have to change the rendering logic for every
chart to be non-monadic. I will play around with your idea.


>  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.


True.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/chart/attachments/20130610/f4daf134/attachment.htm>