Rearchitect Huestacean (again)

[BradyBrenot]

Simplifying, making it easier to add in different frontends, different sorts of lights (targeting Razer and Hue for now), reducing threading difficulties and lock contention, and getting rid of horrifying mess that was v3. Applying better design practices to this whole thing. Let's see what I can manage.

Limitations

• No mechanism for storing settings on the Bridge
• No plan in place for using the GUIFrontend for both local and remote control
  • It needs an abstraction layer between the QML and the Backend that can be swapped out seamlessly for an HTTP (or what have you) client. Huestacean 1/2 had QML talking directly to the "backend", which won't work. I'm going to put off designing this.
  • But, since I'm not sharing data between backend and frontend (see below) this should be easier

Notes

• Use a string interning library, can use strings as IDs
• Minimum of shared properties between classes. Prefer passing data by value
• Two threads used for communication between backend, frontend, and data providers
  • Main thread: Qt messages, GUI, etc.
  • Update thread: The Room/Effects/Lights update loop
• Additional threads will be used by DeviceProviders for uploading / downloading light data asynchronously, but the rest of the application will have no awareness of these and they will access buffered data for thread safety and to avoid contention.
• Double buffer render info within device providers, protect Room with a mutex because it's accessed by two threads (contention will be infrequent, and locking will only happen once per update loop). Avoid adding any other mutexes.
  • Devices are passed by reference, render data (light position, color, etc.) must be Copied by clients to keep them around, avoiding issues that v3 had
• All functions that can be accessed from main thread are responsible for own thread safety.
• dynamic_cast for operator== for Device and Effect
  • These are only being touched by the GUI, and only occasionally, and only one at a time. Performance penalty is super negligible.
• Backend has no knowledge of Frontend ahead of time. Frontend has limited knowledge of Backend limited to a single API presented on the "Backend" class itself.
  • Frontend should have minimal direct communication in the form of signals coming from the main Backend object, but not from anything inside it.
  • Backend should appear as a black box to frontend.
  • This will make it easier to move the backend to a remote host, and to avoid unexpected frontend side-effects happening from backend changes.
• Still using Qt for GUI. It could be useful to expose types to moc so that Frontend's Qml can talk with them easily, but aside from that will prefer avoiding Qt features in Backend, and avoid Qt types in general where Standard Library types exist. Except in Frontend-specific code, that's going full Qt.

Diagrams

[Collisionc]

Just mentioning it because it might be useful to know, but at some point between your 2.0 and 2.5 releases, something broke on shield tv with responsiveness of the lights.

On 2.0 it was right on target, on 2.5 the lights only change brightness/color every 1-2 seconds. I realize that entertainment API requires constantly barraging the hub with commands, so something in the android app is probably not updating the color/brightness variables that are being spammed to the hub often enough.

[BradyBrenot]

I know I messed something up, the bug discussion's in #81.

One goal of this rearchitecture ought to be to add testing as of the build process...

[BradyBrenot]

Updated. Previous design is now dead.

[BradyBrenot]

The bulk of the rearchitecting itself (redesign, new framework to build on) is "done", remaining tasks have been split into separate issues, most important including #119 #117 #126