Dev-mode display using wx?

[lawik]

I think we should be able to draw a bunch of basic pixels (single pixel rectangles) using wxWidgets as a way to have a test output.

It will require a bit more decoupling to work gracefully. But it should be quite useful and an interesting bit of work:

Useful references: https://gist.github.com/rlipscombe/5f400451706efde62acbbd80700a6b7c http://erlang.org/doc/apps/wx/chapter.html#Introduction

[nyaray]

Once the GenServer is implemented, we could:

1. extract a behaviour from InkyIO, probably naming that InkyIO
2. rename the module InkyIO to InkyGPIO and have it implement the InkyIO behaviour
3. add a dev-only option that instructs Inky to use InkyWX instead of InkyIO

My suggestion is that we discuss this further once:

• more tests are in place
• more decoupling has been done after the GenServer is implemented.

[lawik]

Sounds good.

[nyaray]

If we switch our internal representation to use matrices from https://github.com/versilov/matrex we would also be able to visualise the state before writing to the physical screen (see the visualisation examples in the matrex README).

This means that we could turn Commands into a behaviour, minimising the need of trickery required to see what the library believes about the state of the buffer, since it would be even less intertwined with the bit conversion and shovelling parts.

[lawik]

That would be cool but it would also mean a dependency and I rather like how limited this project is with deps so far. So I'm a bit split on this :)

[lawik]

Will be merged when we've refactored commands a bit: https://github.com/pappersverk/inky/pull/17

[lawik]

This is a separate library (https://github.com/pappersverk/inky_host_dev). It is working for master branches on inky and inky_host_dev at time of writing. I've tested it using lawik/sample_inky.

It should be published and stuff. I've no idea if it is worthwhile to try writing tests for it considering it mostly does magical wx-things. I'd suggest holding off on that.

So I'll close this and add one about packaging this dep up for hex release along with Inky and the driver.

[nyaray]

Hm. Shouldn't that library become a dev-only dependency of Inky, then, so that you can run stuff locally when working on an Inky-based project?

[lawik]

Ah, by default? Possibly. Yeah, that'd work. Would still need to be conditionally hooked in somehow. Probably by the user. Or do you have something more in mind. The lib just provides a HAL-module.

[nyaray]

Could the Scenic driver take advantage of this somehow? https://github.com/pappersverk/inky/blob/master/lib/inky.ex#L122

[lawik]

I'm assuming you mean to render using wx on the host for Inky. Not without significant work to get a cross-platform framebuffer-reading-sort-of-deal from what I know.

Considering we can just provide an instruction for Scenic where you render to glfw instead of our driver, I don't think that's a worthwhile thing to pursue. I see it as a largely solved problem.

The only corners not covered is that the glfw thing might look a bit better than we want with all the fancy shades it has. And I call that good enough.

[nyaray]

Do you think it would require too much effort to hack in a down-sampler? :D

[lawik]

Yes. I think it would. And while there is a point, I don't see it being worthwhile. I've no plans to at this point :)