Dev-mode display using wx? about inky HOT 12 CLOSED

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.

from inky.

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 :)

from inky.

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.

from inky.

Sounds good.

from inky.

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.

from inky.

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 :)

from inky.

Will be merged when we've refactored commands a bit: #17

from inky.

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?

from inky.

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.

from inky.

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

from inky.

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.

from inky.

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

from inky.