Define signals the UI emits to start, stop, and pause processes about capstone-project HOT 3 CLOSED

This is done with the exception of device status, you said that you had an idea for how to implement this cleanly so we probably need to sit down and talk about how exactly this is going to be done.

from capstone-project.

So there needs to be two things happening:

1. Functions (or a function, you might only need one) that reads the device handler's Hardware State and updates the UI elements.
2. Functions that call the relevant component control functions in the device handler.

Right now you have functions that do both at the same time, the problem with that is you're assuming the requests will be successful and not verifying, and you don't have the means to update the screen when a process changes something automatically. Decoupling the control requests and UI update will solve that issue.

You also added a bunch of your own "state" variables, but that's what the hardware state class is for. You can just read the device handler's instance of that class, which will give you a comprehensive and up-to-date reflection of all the component statuses, including the sensors. You can read it directly every line or copy it to a local variable to save yourself some typing as you read each component, because it's by reference it doesn't make a difference.

from capstone-project.

This should be done unless I forgot something, or we think of something to add to this.

from capstone-project.