2.8 KiB
Architecture
If you want to understand the high-level architecture of helvum, this document is the right place.
It provides a birds-eye view of the general architecture, and also goes into details on some components like the view.
Top Level Architecture
Helvum uses an architecture with the components laid out like this:
┌──────┐
│ GTK │
│ View │
└────┬─┘
Λ ┆
│<───── updates view ┌───────┐
│ ┆ │ State │
│ ┆<─ notifies of user input └───────┘
│ ┆ (using signals) Λ
│ ┆ │
│ ┆ │<─── updates/reads state
│ V notifies of remote changes │
┌┴────────────┐ via messages ┌─────────┴─────────┐
│ Application │<╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤ Seperate │
│ Object ├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌>│ Pipewire Thread │
└─────────────┘ request changes to remote └───────────────────┘
via messages Λ
║
║
V
[ Remote Pipewire Server ]
The program is split between two cooperating threads. The GTK thread (displayed on the left side) will sit in a GTK event processing loop, while the pipewire thread (displayed on the right side) will sit in a pipewire event processing loop.
The Application object inside the GTK thread 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 pipewire thread updates the state and notifies
the Application in the GTK thread if changes are needed.
The Application then updates the view to reflect those changes.
Additionally, a user may also make changes using the view.
For each change, the view notifies the Application by emitting a matching signal.
The Application will then ask 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
TODO