Allow other Input implementations

[bartcerneels]

This enables alternative implementations that could, for instance, use
ESP touchpads:

from touch import Touch

prv = buttons.touch_0
sel = buttons.touch_1
nxt = buttons.touch_2

class TouchInput:
    def __init__(self, prv, sel, nxt):
        self._prev = Touch(prv, 0)
        self._sel = Touch(sel, 1)
        self._next = Touch(nxt, 2)

        self._prev.press_func(Screen.ctrl_move, (_PPREV,))
        self._sel.release_func(Screen.sel_ctrl)
        self._next.press_func(Screen.ctrl_move, (_NNEXT,))

    def precision(self, val):
        Screen.redraw_co()

    def adj_mode(self, v=None):
        Screen.redraw_co()

    def is_adjust(self):
        return False

disp = Display(ssd, input=TouchInput(prv, sel, nxt))

[peterhinch]

I would suggest passing the Input class to the constructor rather than an instance, then you wouldn't need to assign defaults to nxt and sel:

class Display:

    def __init__(self, objssd, nxt, sel, prev=None, incr=None, decr=None, encoder=False, IPClass=None):
        global display, ssd
        IP = Input if IPCLass is None else IPClass
        self.ipdev = IP(nxt, sel, prev, incr, decr, encoder)

This preserves the logic of requiring, as a minimum, nxt and sel objects.

My main concern is how to document the creation of user Input classes, which could be nontrivial.

[peterhinch]

Thank you for this excellent idea. I've now pushed an alternative implementation. Unlike my previous suggestion this enables alternative input classes without imposing any restrictions on their constructor args.

If you wish to offer a complete 5-button solution for ESP32 touchpads I'd be happy to publish it (with credit to yourself, of course). I'm sure such a class would find users.

[peterhinch]

Looking at this some more, while I think abstracting the input class is a great idea, I'm not sure it's the simplest approach for the specific case of ESP32 touchpads.

[EDIT] to remove heat-related nonsense:

I have written a Touchbutton primitive which has the same API as the Pushbutton class. It seems to work quite well, supporting all the callbacks of Pushbutton and the suppress arg.

If we were to write a new Input class it would therefore be a copy of the existing class, the only change being to replace instantiating Pushbutton objects with Touchbuttons. This seems poor. There are a few ways to fix this - I'm still trying to figure out which is best.

[peterhinch]

I've pushed an update on branch touch. The GUI requires further testing in this mode before I merge it.

The Display function has an additional touch=False arg. In hardware_setup set this True and ensure that Pin instances are touch compatible. It's probably best to define these without pullups. Touch pins can be used with an encoder but this must have physical contacts :)

[peterhinch]

I have merged the branch and pushed an update. The touchpad interface works fine in my testing and the README.md is updated, so I believe this is complete.

I have also updated the async library to support the callback interface for touch pads.

Thank you for prompting me to do this. Observations or comments are welcome.

[bartcerneels]

Hey Peter

I've been on holiday and some post-holiday corona recovery.
Thanks for taking the suggestion and adding Touch. I'll try to rebase my work and use upstream when possible. Only have a few days left before we produce the Fri3dcamp badges.

[peterhinch]

Sorry to hear you've been ill.

I have been impressed how well the touch interface works, both independently and with the GUI. Good luck with the badges.