-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: Proposals for new ways to interact with setUI #3452
Conversation
Thanks - extending to add the handlers looks good, but the whole |
**/ | ||
swipe : swipeHandler, | ||
btn : buttonHandler, | ||
btnEdge : "rising", // TODO: Proposal: a new, optional, way to choose what edge the button(-s) should act on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gfwilliams what do you think of the idea to be able to specify the desired edge like this or some other way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I was going to say this didn't feel great but I couldn't think of a better way...
But then I was thinking: "What if you want to do different things on Rising and falling edges?"
So what if we had btn
(as before) but then btnPress
/btnRelease
callbacks could be specified? That feels like maybe a tidier solution? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... the only downside of this is I guess it's not easily backwards compatible - but if we want this stuff to work outside of the mode:custom
then maybe that doesn't matter as it wouldn't work now anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I agree with your callbacks solution being tidier.
But just regarding this:
But then I was thinking: "What if you want to do different things on Rising and falling edges?"
I'm not saying it's the better solution, just another one. If "both" was specified in my example above that could be passed on to the setWatch
call inside setUI and then the buttonHandler
function would be responsible for handling both edges.
And if you feel callbacks are better that carries much weight for me :)
`btn` can be set like before, so backwards compatible I think. But it can now also be an object on form {fn: ()={}, edge: "rising/falling/both"}. @gfwilliams has suggested another solution using callbacks in espruino/BangleApps#3452 (comment) The solution I opted for here for now follows the same coding style of how the `type`/`mode` parameter of setUI can be either a string or an object.
This is not meant to be merged - only for providing an example/proposal for changes to how we can interact with Bangle.setUI. This is an addition to the discussion at #3435.
The diff has comments explaining my thoughts.