Merge Controller and View structs into one Application struct.

The `View` sturct was mostly a layer of indirection, and the controller benefitted by absorbing the gtk::Application
subclass parts, so now those two are merged into a new gtk::Application subclass.
This commit is contained in:
Tom A. Wagner
2021-05-08 17:12:04 +02:00
parent 2cc684d57c
commit be240231c0
7 changed files with 276 additions and 348 deletions

View File

@@ -10,6 +10,7 @@ Helvum uses an architecture with the components laid out like this:
```
┌──────┐
│ GTK │
│ View │
└────┬─┘
Λ ┆
@@ -20,11 +21,10 @@ Helvum uses an architecture with the components laid out like this:
│ ┆
│ ┆
│ V notifies of remote changes
┌┴───────────┐ via messages ┌─────────────────────
│<╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤ Seperate
Controller │ │ Pipewire
│ ├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌>│ Thread │
└┬───────────┘ Request changes to remote └─────────────────────┘
┌┴───────────┐ via messages ┌───────────────────┐
Application │<╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤ Seperate │
Object ├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌>│ Pipewire Thread
└┬────────────┘ request changes to remote └───────────────────┘
│ via messages Λ
│ ║
│<─── updates/reads state ║
@@ -38,17 +38,17 @@ The program is split between two threads, with most stuff happening inside the G
The GTK thread will sit in a GTK event processing loop, while the pipewire thread will sit in a
pipewire event processing loop.
The `Controller` struct inside the GTK thread is the centerpiece of this architecture.
The `Application` object inside the GTK thread is the centerpiece of this architecture.
It communicates with the pipewire thread using two channels,
where each message sent by one thread will trigger the loop of the other thread to invoke a callback
with the received message.
For each change on the remote pipewire server, the GTK thread is notified by the pipewire thread
For each change on the remote pipewire server, the `Application` in the GTK thread is notified by the pipewire thread
and updates the view to reflect those changes, and additionally memorizes anything it might need later in the state.
Additionally, a user may also make changes using the view.
For each change, the view notifies the controller by emitting a matching signal.
The controller will then request the pipewire connection to make those changes on the remote. \
For each change, the view notifies the `Application` by emitting a matching signal.
The `Application` will then request the pipewire thread to make those changes on the remote. \
These changes will then be applied to the view like any other remote changes as explained above.
# View Architecture