Comments (5)
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.
Related Issues (20)
- Experiment with higher SPI speeds HOT 9
- Consider making the busy waits into aspects of sync/async updates HOT 7
- Add credo check to CI
- Replace custom mock hackery with Mox HOT 2
- Add a convenient way to get display info by type HOT 2
- Allow setting an optional rotation
- Implement a post-push signal that can be requested by callers of `set_pixels` HOT 2
- Host dev library should handle border
- Not working with wHAT display HOT 17
- Update commands to be in line with current Python Inky HOT 3
- Clean up IO tests to use hex or constants in comparisons HOT 4
- Use constants or something elegant for all the magic numbers HOT 3
- Version 1.0.1 cannot compile on Elixir 1.10 HOT 3
- Support the Inky Impression HOT 10
- display orientation upside down HOT 5
- Dev-mode display using wx? HOT 12
- set border color at creation and after creation HOT 3
- should we support the red high temperature screen type? HOT 2
- Validate display size on init HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from inky.