Thanks - do you think maybe the slider library should just be in modules rather than being a whole separate app with icon/etc? Seems like it's probably more sensible for such a small bit of code?

do you think maybe the slider library should just be in modules rather than being a whole separate app with icon/etc?

I was wondering about that actually. Does it make sense to develop it like this and change it to that when it's ready for merge?

Does it make sense to develop it like this

Up to you really - whatever you find easier. If you're developing with just the IDE you can have two files open now, one of which is the module and one of which is the app, and that should work nicely.

@gfwilliams would it make sense to make this compatible with Bangle.js 1? Or is the ram constraint too narrow so it isn't worth it to implement it?

The Bangle.js 1 doesn't provide any x/y touch input (it's just two areas) and there are no overlays so I don't think this makes sense.

Come to think of it, I see you using overlays here - is that really needed? Putting up an overlay is a lot slower than just updating the screen, so if there's a way of doing this without overlays it seems that'd be better.

Thanks!

The Bangle.js 1 doesn't provide any x/y touch input (it's just two areas) and there are no overlays so I don't think this makes sense.

Ok, I was thinking of maybe using the LR-swipes on bangle 1.

Come to think of it, I see you using overlays here - is that really needed? Putting up an overlay is a lot slower than just updating the screen, so if there's a way of doing this without overlays it seems that'd be better.

Ok! I opted for overlays to not mess with the other graphics of the current app. So that when the slider times out and goes away the graphics behind is still there. But maybe that can be achieved without overlays also? Or otherwise, maybe it's better to expect the app to draw again when the slider timed out?

Thanks! I'm just a bit anxious that right now we assume that apps aren't using overlays - for instance if Messages Overlay or the widget_utils.swipeOn has call to use them and your slider is active, it'll probably just end up removing your overlay while all your touchscreen handlers stay active. I'd sort of assumed they would be used quite rarely so there's nothing implemented to handle stacking them or restoring old ones.

I might be better to assume the app will redraw. I recently added:

Bangle.setUI({
  mode : "custom",
  // ...
  redraw : function() {},
});

Which is in cutting edge builds (and will be released in 2v19) which showMenu/showPrompt/showScroller all implement - so if you're planning on using the slider from E.showMenu that could be a neat option?

Although it's probably not a big deal to just ask the caller to redraw in the callback, and it might be safer

• when using one persistent slider and one temporary, stop the persistent one not being redrawn when the temporary one goes away.

One solution here would be to:

1. remove the persistent slider when the temporary one goes away, similarly to how timeouts and event handlers can be removed by referencing them.
2. reinitiate the persistent slider.

But I currently don't know how to achieve step 1.

Edit: I can probably refactor to do like the top answer here: https://stackoverflow.com/questions/25199343/javascript-calling-a-inner-function-from-outside. Don't know if it's the best route.

Looks like you're still doing a bunch of work on this, so maybe I'll hold off merging until things calm down a bit?

@gfwilliams, I think this is OK to merge, and would be happy to have it be so. The remaining checkboxes can be handled in another PR I think.

But also, I would be interested in what you think about the naming of things before the initial introduction to the main repo. If you see anything apparent regarding that it could be good to take it into account before merging.

Thanks! I had a look and as far as I'm concerned, that naming all looks pretty good.

Layout does use col/bgCol and this uses colorFG/colorBG but honestly I don't think that's really a big deal - it's not like the choices for layout were very clever, I was just trying to keep the names short so less space was used when you had lots of Layout objects (but chances are you'll only ever have a few sliders so that doesn't matter)

Ok!

Thanks for the help on this @gfwilliams and @bobrippling 😊

My pleasure, glad to see this slider work finished! Thank you too!