servius/helvum
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/helvum synced 2026-03-15 03:26:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update ARCHITECTURE.md to reflect state having moved to the pipewire thread

Browse Source
This commit is contained in:
Tom A. Wagner
2021-06-06 09:36:57 +02:00
parent 907ef328d2
commit 92101d860c
1 changed files with 21 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/architecture.md
View File

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