-
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: HW buttons should act on 'rising'
edge
#3435
Comments
Probably relevant comment:
Originally posted by @gfwilliams in #3297 (comment) |
Maybe I can try this out by overwriting |
Yes, you could try overwriting those functions and see what happens - overwriting setWatch might be enough, and maybe it's something you could even provide as an app. But personally I don't think this is something I'd be interested in changing, because of the long-press issue. One of the major issues folks seem to take with the Bangle is the lack of buttons, so removing the ability to get long press info out of the button feels like a bad move. |
I might give overwriting setWatch a try then. |
Now you've bought it up I'm more aware of how long I end up pressing the button for before releasing :) Try adding: {
let _setWatch = setWatch;
global.setWatch = (fn,pin,opt) => {
if (opt && opt.edge && opt.edge!="both") opt.edge = "rising";
return _setWatch(fn, pin, opt);
};
} to custom boot code (or any file called It doesn't immediately break things, and it does feel snappier after. If it doesn't screw stuff up too much it might be worth making it a 'beta' app... |
Thanks! I'll check that out :) |
Ok - yes my watch feels substantially much more snappy! :) |
Compilation of APP - PROBLEM when running the boot code from #3435 (comment):
Ideas for fixing/working around problems
|
Came out of this discussion: espruino#3435
Came out of this discussion: espruino#3435
Came out of this discussion: espruino#3435
Came out of this discussion: espruino#3435
Came out of this discussion: espruino#3435
Actually it does say:
and then
but I'll delete the initial default comment
My concern is we'll end up with other places we need to add all these little hacks too. Perhaps we can do something like However I think the long press to get home issue is probably going to be a much bigger deal. I mean literally any app that uses the button for anything except exiting to the clock will suffer from this problem if someone long-presses the button, and I wonder if there's really a way around it? I'm sure someone will arge that having some apps respond on one edge and others respond on the other is confusing as well. |
Yes, very sound arguments. I'm happy with just using the boot code you posted above for a bit. Not sure if we should do system wide changes either but the snappiness is nice 😉 Edit: thank's for pointing out the docs. Sorry for not reading thoroughly.. |
Well, thanks for pointing out the issue. Most people (including me) only glance at the docs anyway, so we don't want the summary up top to be wrong. Thinking about it, the cases where we could respond quickly and it wouldn't be a problem are where the button press effectively does what a long press would do anyway/doesn't really have an effect, so:
And I guess those handle a good 80% of use cases anyway? So maybe rather than overriding |
Yes that sounds like it would be mostly problem free! I guess some app may add additional button watches after a setUI call which may be problematic. Don't have an example right now though. Edit: but that shiuldn't really work today either right? |
True... In a way it'd be good to know those so they could be changed to use setUI for everything... |
Searching files that contain
|
So in cases where setUI uses a
|
I think in that case, doesn't the button end up calling the function with We could extend setUI so that even if mode!=custom, button/touch/swipe/etc are still honoured? |
Sorry, I changed/messed up the code before commenting - I updated the code block above now to reflect the actual code in the repo. There's no
That's what I'm leaning toward as well. It's nice being able to use the preconfigured behaviours but add on to them when you want to. |
If you do:
I think that has mostly the same effect looking at setUI - although there is an issue that touching the screen would take you back. I'd be happy to change setUI as it should be backwards compatible, but obviously any apps you change wouldn't work unless you had the newer Bangle.setUi version |
OK! Maybe we update setUI soon-ish and wait with merging updates to the apps until after stable fw 2v23 is out? |
Sounds like a good plan, yes |
Added an example on how we might be able to interact with setUI after an update of it: #3452 |
I guess this is somewhat similar to the
I found I needed a case like this recently, can't remember the app now though |
The problem is that the whole point is to do the action as soon as possible, so the action is performed, but then ~1 sec later for the long press we exit the app. We can't use I guess for run/runplus the solution would be to swap the visible recording state when the button was pressed so it looked fast, but to only actually make the change when the button was released? But the actual visible change is so minimal I think it probably makes sense just to explicitly request the falling edge |
Just a note to say I don't want to rush this. There's obviously some deliberations to be had so we can land on a good solution. |
Came out of this discussion: espruino#3435
TODO: Not thoroughly tested yet. First discussed here around here: espruino/BangleApps#3435 (comment)
To make the ui feel snappier. First discussed around here: espruino/BangleApps#3435 (comment)
To make the ui feel snappier. First discussed around here: espruino#3435 (comment)
Came out of this discussion: espruino#3435
Just posted about this on the forum: https://forum.espruino.com/conversations/397606/ Also I realised Layout detects long presses and could be an issue, but it uses setWatch directly so is ok: https://github.com/espruino/BangleApps/blob/master/modules/Layout.js#L107-L117 It could detect if there's a no |
To make the ui feel snappier. First discussed around here: espruino#3435 (comment)
I recently watched "Theo - t3.gg" discuss a twitter post from John Carmack talking about using edge
'rising'
vs'falling'
and user experience. The take home message being to act on the'rising'
edge when it's possible. Here's the video: https://www.youtube.com/watch?v=yaMGtiPckAQIn the name of responsivness I wonder if it would make sense to adhere to this way of thinking when programming the hardware button on the Bangle.js.
I have personally made changes from
'rising'
to'falling'
edge responses as to not leave a'falling'
edge for a subsequent screen to pick up - I was seeing some bug related to this (one reference). Now I find myself wanting to go the other way.To avoid unexpected/unwanted interactions on a left over
'falling'
edge, could some default behaviour of disregarding just the'falling'
edge event if it occurred within a short time after thesetWatch
was called be implemented? If not insetWatch
then maybe insetUI
? Or could this be solved by changing the default of reacting on'both'
to instead use'rising'
?Really I just wanted to discuss if others also thinks this is worthwhile. Maybe it's a lot of work, complicating the logic and not backwards compatible. But I want as much snappiness as possible out of the watch! :P
The text was updated successfully, but these errors were encountered: