jtdaugherty/vty

Export Graphics.Vty.Image constructors

ramirez7 opened this issue · 4 comments

I'm writing some BearLibTerminal bindings for Haskell and I thought one good use of them could be a vty backend [1]

The Vty type seems nice and abstract (record of functions) so I think I could just implement that..however when I dug deeper, I think I cannot implement update :: Picture -> IO () because Image (within Picture) does not export its internals, so I cannot do anything with that type.

[1] BearLibTerminal is cross-platform with Windows support. In addition, it has proper layering, which could play nicely with vty's existing layers.

That's a neat project!

Before I agree to export the Image constructors, I think it would be helpful if you could do your work against a fork with the constructors exported just to see how far that will get you. Implementing a new backend for vty that is not actually a terminal might run into some design assumptions that need to be surfaced, and the library is not designed with this use case in mind. Even having access to Image constructors will still leave you with a lot of work to do since the images will need to be rasterized; that work happens in PictureToSpans.hs in displayOpsForPic. I suspect that rather than dealing with Image yourself, it would be much better to deal with vectors of SpanOps values that get produced by the library. That will reduce the chance that your re-implementation of the rasterization is wrong or different from Vty's implementation in subtle ways.

@ramirez7 Thoughts?

Oh sorry I forgot to ack!

Yeah I think that sounds like a good plan. I'll look into the SpanOps stuff. It's possible I'll want to have the option for rasterization to be wrong from Vty's to allow the user to take advantage of BLT's tile composition. But your suggestion will be useful to help me provide an option for parity as well.

@ramirez7 I'm going to close this since it's been a while; please re-open if needed!