feat: ✨ Screen api wrapper #66
Conversation
| * @brief Subscribes the listener to be called when the screen touch state changes. | ||
| * | ||
| * Spawn a new task to check for events if it is not already running. | ||
| * All listeners are called from this task. |
There was a problem hiding this comment.
IMO we should either use a separate task for every callback, or not have this functionality built-in.
There was a problem hiding this comment.
Perhaps. My thinking is that if we have a good mechanism to warn the user at runtime that something bad is going on (via the brain screen), then one task should be good. There was also a large discussion about this in discord and about supporting event listeners for device updates.
| std::optional<Screen::TouchEvent::State> filter; | ||
| }; | ||
|
|
||
| static std::vector<Listener> listeners; |
|
|
||
| // TODO: Determine when it starts counting | ||
| /** The number of times the screen has been pressed. */ | ||
| int32_t pressCount; |
There was a problem hiding this comment.
Why are the counts signed integers?
There was a problem hiding this comment.
Comes from this
May also have to do with vex sdk api, but I'm not sure.
Likely would be good to make unsigned
| #pragma once | ||
|
|
||
| #include "pros/rtos.hpp" | ||
| #include "stdint.h" |
There was a problem hiding this comment.
| #include "stdint.h" | |
| #include <cstdint> |
| #include <utility> | ||
| #include <vector> | ||
|
|
||
| #ifndef ZESTCODE_CONFIG_SCREEN_TOUCH_LISTENER_TASK_INTERVAL |
There was a problem hiding this comment.
What's the point of this code? Users can't change the #define value without editing ZestCode's source code anyways.
There was a problem hiding this comment.
Since the user compiles zest code themselves as part of the build process, they can define this macro when calling the compiler thru a cli option.
Overview
A friendlier, documented and safer API wrapper around the Vex SDK.
Motivation
Gives users a documented and safe api to interact with.
References (optional)
Implementation Details (optional)
on_pressed()/on_released()should not usevexTouchUserCallbackSet(), since then the callback would be called within the system_daemon task.This would enable a user to mistakenly delay within the callback and prevent the program from receiving new device data, as
vexTasksRun()would not be run.NOTE: document the above in source
Test Plan:
TBD