backswipe_edge: swipe from the right edge of the screen to go back

[ssievert42]

This allows going back by swiping from the right edge of the screen, Android style.

I hacked this together to prevent my button from dying (again).

Not sure if this needs some sort of calibration / settings, but loading a config file at boot seemed like it would slow down load times a bit.

Has been working fine as far as I can tell :)

[thyttan]

Didn't test but looks good I think. One question re pixel counting in review.

[thyttan]

Nice idea with the edge, so you don't need to count active swipe and drag handlers like we do in backswipe 👍

[ssievert42]

Nice idea with the edge

Thanks :)
Although, as the description says, that idea is borrowed from Androids gesture navigation mode.

I guess it would also be possible to draw a little back arrow with an overlay, but you'd probably not see it below your finger 🙈

[RKBoss6]

There's already a backswipe app, so would it make more sense to just modify that to have a setting for direction, rather than making a new app?

[thyttan]

There's already a backswipe app

I think the logic and design choices are different enough for it to make sense as a new app :)

[bobrippling]

I guess it would also be possible to draw a little back arrow with an overlay, but you'd probably not see it below your finger

Yeah I was wondering about this - we could offset it into the middle of the screen but we have the problem of redrawing the original UI when the arrow's gone. Or we could draw the arrow using the overlay

[thyttan]

I guess it would also be possible to draw a little back arrow with an overlay, but you'd probably not see it below your finger

Yeah I was wondering about this - we could offset it into the middle of the screen but we have the problem of redrawing the original UI when the arrow's gone. Or we could draw the arrow using the overlay

Maybe we can do paint over the back button so it "flashes"? Then we wouldn't have to worry about the rest of the screen.

Either way I suggest leaving that for a later version :)

[bobrippling]

Maybe we can do paint over the back button so it "flashes"? Then we wouldn't have to worry about the rest of the screen.

Yeah that could be cool - I do like the vibrate as feedback too, tried it out and it feels just right

[ssievert42]

Thanks for the review and feedback :)

I think I should've addressed all suggestions up until now; no idea how I managed to forget to fill out the "author" field 🙈

Painting over the back button sounds like a neat idea 👍
But yea, probably best left as a feature for a follow up to this.

Accounting for touchscreen calibration seems to work with

Bangle.setOptions({touchX1: 0, touchY1: 0, touchX2: 160, touchY2: 160});
Bangle.setOptions({touchX1: 10, touchY1: 0, touchX2: 180, touchY2: 160});
Bangle.setOptions({touchX1: 0, touchY1: 0, touchX2: 140, touchY2: 160});

which should ideally sort of somewhat cover real world touchscreen calibrations.

[thyttan]

Would you mind if we changed the id to backswipeedge without the underscore? Shorter names are a little bit faster and most apps don't use underscores in the id. I would have probably even done backswedge but that's probably a step too far :P

[bobrippling]

Changes look great to me, thanks for the nice app idea btw! And good thinking both of you with the touchscreen calibration

[ssievert42]

Would you mind if we changed the id to backswipeedge without the underscore?

Not really set on the name, so can do 👍

But would the name really make much of a difference if everything is copied to .boot0 anyways?

On the topic of shorter names being faster: I changed calib to cal, which I think is still readable enough.

Maybe for hooking up the back button, the backswipe event could get a type parameter?
Something along the lines of:

• 1: started (will go back on finger up)
• 2: cancelled
• 3: go back

So we could do:

Bangle.on("backswipe", (type) => {
  switch (type) {
    case 1:
        // make back button flash / change color
        break;
    case 2: // fallthrough
    case 3:
        // return back button back to normal
        break;
  }
});

[thyttan]

I think it's time to merge :) what do you say?

[ssievert42]

the backswipe event could get a type parameter

Please disregard that last bit; I just assumed that the back button widget was an app and not part of the firmware https://github.com/espruino/Espruino/blob/654b3a3847392741bffd6c5b149a42f82844f692/libs/js/banglejs/Bangle_setUI_Q3.js#L143-L157

Modifying the back button sources to respect this app also seems like a bad idea; we could patch the draw function of WIDGETS.back instead though?
That way people who haven't installed this app are not running any extra code to accommodate this app at all times.

Also, the drag handler seems like a prime example of something that can be thrown at the jit for a bit of extra perf, or could that cause issues?

I think it's time to merge

If there aren't any objections to using the jit I'd like to do that, but the back button flashing thing is probably really best left for the future™ so 👍

[ssievert42]

JITing the drag handler seems to work alright; I've just pushed that change.

This should be ready now :)

[ssievert42]

On the topic of making the back button "flash":
Behold my unholy patching stuff to make the back button turn green https://github.com/ssievert42/BangleApps/tree/backswipeedge_change_back_button (It actually works 🙈)

[thyttan]

If jit works that's great! Have you looked through https://www.espruino.com/JIT and https://github.com/espruino/Espruino/blob/master/README_JIT.md ?

I usually do "ram" keyword for perfmance but have not learned when to use "jit". I wonder if they would work together as well 🤔

[bobrippling]

JITing the drag handler seems to work alright; I've just pushed that change.

Nice! Like @thyttan says, jit is buggy in places but if it works well under test then the language features being used are likely fine here

On the topic of making the back button "flash": Behold my unholy patching stuff to make the back button turn green https://github.com/ssievert42/BangleApps/tree/backswipeedge_change_back_button (It actually works 🙈)

That is rather unholy! The pattern a lot of apps use for overwriting is to copy the code and tweak it, which in this case is probably less of a diff than modifying the function code at runtime. But we can discuss in a separate PR :)

[thyttan]

For flashing the button I had a naive solution in mind just painting at the same position of the widget but not really interacting with it. Patching the widget may be better though? Without working it through it feels like it takes a bit more logic, but shouldn't matter.

[ssievert42]

Have you looked through https://www.espruino.com/JIT and https://github.com/espruino/Espruino/blob/master/README_JIT.md ?

👍

Everything we're doing here should ideally fall under the "works" category.

That is rather unholy!

I know, right? It's probably only a matter of time before that breaks, so copying and then modifying the code sounds like a better idea (for a future PR).
I'd prefer adjusting the code to drawing over the widget; that way the widget redrawing itself ideally has less of a chance of breaking things.

[thyttan]

So we go ahead? 🙂

[ssievert42]

Yes, please 👍

Also, thanks again for the review, feedback and stuff :)

[thyttan]

Thanks 😁

[bobrippling]

I'd prefer adjusting the code to drawing over the widget; that way the widget redrawing itself ideally has less of a chance of breaking things.

Sounds good - you may find widget_utils's hiding interesting inspiration

And thanks for the PR!