GenServerify the main entrypoint, Inky (inky.ex) about inky HOT 5 CLOSED

Looks pretty good to me. The set function might be a bit overloaded with those options but with this API-surface it should be fine :)

from inky.

The options actually help keep the api simple, as they minimise the amount of "does the thing... and also x,y in z way" functions since the options are orthogonal from setting pixels. In other words, the overall api becomes simpler since the pixels are set in one way.

The word "overloaded" struck a chord with me, though... I'll update the API suggestion!

from inky.

That API surface is more easy to understand. But maybe you were right that set_pixels(pid, data, opts) is all we need. So we can skip show and show_async.

I think we can just remove set_pixel for single pixel changes. That just encourages unoptimizable behavior.

set_fill is a good utility. Though I'd love to remove it just to minimize the API. I wonder if we should expose some kind of iterate-over-your-pixels-with-double-reduce functionality where you pass your own callback. Not part of this API-surface. But maybe a nice util. And then we could just have a get_fill util there.

So Inky would expose:

• start_link
• set_pixels

Inky.Util would expose:

• fill(color)
• generate_pixels(your_fancy_function) your fancy function takes (x, y) and returns a color atom.

I'm aware I'm going back and forth on those opts. You are making me think, I'm not sure I like it ;)

from inky.

I think we can just remove set_pixel for single pixel changes. That just encourages unoptimizable behavior.

I disagree. If you set active: false, no internal call to show will be made.

set_fill is a good utility. Though I'd love to remove it just to minimize the API. I wonder if we should expose some kind of iterate-over-your-pixels-with-double-reduce functionality where you pass your own callback. Not part of this API-surface. But maybe a nice util. And then we could just have a get_fill util there.

How about this, I'll trade my set_fill for your generate_pixels, but instead we call it map_pixels(x,y) :: color, how does that sound? That way, we generalise and set_fill becomes a shorthand you can throw in as a callback from that utility you mentioned... But get_fill is weird and only valid for some states and thus, not general enough to exist, imho.

I'm aware I'm going back and forth on those opts. You are making me think, I'm not sure I like it ;)

The opts pattern is established for a reason :). EMBRACE the think-discomfort.

from inky.

I don't mind the pattern of opts as such. Just didn't feel like the clearest and most discoverable. But I think it gives the right flexibility in this case.

We have an accord on the map_pixel 🤝

from inky.