Separate frontend state handling from core state
Description
NOTE: This is a WIP Merge Request, though I am soliciting feedback on whether my general approach is appropriate.
Changes proposed in this merge request:
- A new State class that holds the information that we want to store and make available to the frontend.
- Stream owns a State that it reports changes to (receiving the changes via callbacks passed to the scheduler)
- App passes some callbacks to the Stream's State (via Stream) that it uses to subscribe to changes to the core State.
- App uses those callbacks to update its own frontend-side copy of State (because I'm lazy and need to store the same information)
- The frontend's LogLine widget and Status widget receive a copy of the frontend's State, and read that instead of accessing the scheduler's queues.
NOTE: I am not sure about the state stored in the core, specifically because it isn't used in the core, just the frontend. I've suggested some alternatives in https://mail.gnome.org/archives/buildstream-list/2019-June/msg00022.html, and my favourite at the moment is to just have a defined interface on the Core side, instead of holding all the state.
This merge request is part of (but will not close) : #1029
Edited by Jonathan Maw