Main classes: Widget and Control

[kmatch98]

This PR adds the primary main classes that define the baseline structure of the Widget and Control classes.

The main discussion related to the structure is located in this issue.

[kmatch98]

This is ready fo review. I have simplified the earlier draft PR by just pulling out the main class definitions for Widget and Control. I have not included any widget examples here but the draft PR includes several that will eventually each have their own PR.

Main objective of this review is to get feedback on the class definitions and whether these two classes have the right structure to accommodate an assortment of future graphical widgets, including those with touch response.

Some lingering questions to spur discussion:

• In the absence of using interrupts, we will rely on a main loop to handle touch events and call the appropriate widgets. In my current widgets, and widget actions are blocking (such as animation of a switch moving). Do we instead want “non-blocking” widget response functions and then a separate “redraw” widget function? If so, the main loop will need to call the “redraw” function on each widget in case any redrawing is required (such as during animation) while the main loop can still watch for touch inputs.
• Should each widget have a built-in option for a label? Currently I kept a place holder name for this.
  - Benefits: new users could use one command to add a widget and also label it.
  - Cons: Not all widgets have an obvious place to put a label, and a separate Widget_Label could do the same job.
• Are there other class variables or response functions that should be added to cover a broader set of use cases?

Thanks for your input!

[FoamyGuy]

These are looking pretty good to me. I noticed a few docstrings that need tweaked, and I had a few other questions.

I can share my thoughts on the questions you asked as well:
Q1: I think I am in favor of making them blocking and not having the user rely on calling an update or animate function in their main loop. The animation should be taking too long (though that depends a lot on the use case as well). And I think it's better to block so that it can complete uninterrupted. If user needs no block they could set animation time to 0.

Q2: I think I lean towards no name by default even though it would make some use cases a little easier. It's not a super strong opinion though, I'm open to other thoughts on this. If we do build it in to widget I think it would be best if it can be done in such a way that if the user is not using it then they can still use their widget without needing display_text library on their device (assuming they aren't otherwise using it.)

Q3: for the short / medium term I think this set that you have is good. If anything I might be in favor of removing a few until we get a more fleshed out event system in place. I'd maybe get rid of gesture_response, released, and still_touched. They could get added back in once we have something specific that is using them.

It's definitely a larger discussion than for this PR, but in the longer term I wonder if there is any opportunity for a core module to interact with a touch screen "in the background" and cache events for us waiting until the user code checks for them. Similar to how displayio renders in the background, and gamepad manages button state in the background.

[kmatch98]

I made major updates to the documentation and was able to build them on my machine.

However, the checks failed here due to Pylint. It's complaining about repeated code use in the examples folder. Strange. I suspect this is due to some unknown changes in the pylint settings. @kattni will look into this and see if there is a way around it.

Please wait until that is resolved before spending any time on this, since the documentation is probably the biggest change added in the latest commits. Let's give it a few days to get resolved and then can review once the docs are built.

[kmatch98]

Update on Q1 above.

There are asynchronous (async) features that have been added recently:

• https://github.com/WarriorOfWire/tasko
• __await__ magic method and async/await circuitpython#3540

This can come in handy for the widget redraw functions and the touch response handler.

But for now let’s keep the redraw code as blocking, and explore this async capability in the future.

[kmatch98]

Thanks to the recent pylint fixes, this is now passing.

@FoamyGuy I'd appreciate if you would take a quick look to verify I addressed your comments.

[FoamyGuy]

These are looking great to me after the latest changes. Thank you! I think this is ready to merge any time. Let me know if there is anything you know of we need to hold back for @kmatch98. If not i'll be back this evening to merge this.