sorb/ThreadNet-Web
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 4 Wiki Activity

[MEDIUM] Settings normalisieren: Video/Audio-Einstellungen nur im Call-Widget, nicht im Haupt-Client #3

New Issue
Closed
opened 2026-07-29 18:25:52 +00:00 by sorb · 1 comment
sorb commented 2026-07-29 18:25:52 +00:00
Owner
Copy Link
Copy Source

Beim Durchgehen der Einstellungs-Oberflächen aufgefallen: Element Web (der
Haupt-Client) und Element Call (das eingebettete Widget) haben getrennte, sich teils
überschneidende Settings-UIs für Audio/Video, ohne erkennbare Synchronisation.

Konkreter Ist-Zustand:

  • Element Web hat einen eigenen "Voice & Video"-Tab
    (apps/web/src/components/views/settings/tabs/user/VoiceUserSettingsTab.tsx) mit:
    Audio-Eingabe-/Ausgabegerät, Video-Eingabegerät, sowie Echo-Cancellation/Noise-Suppression/
    Auto-Gain-Toggles.
  • Element Call (unser Fork, threadnet-call) hat im "Video"-Tab (heute erweitert,
    Issue #8/#11-Kontext) eigene AudioProcessingSettings (dieselben drei Audio-Toggles!) UND
    die MediaQualitySettings (Auflösung/Framerate/Bitrate/Codec für Kamera + Screen-Share).
  • Überschneidung: die Echo/Noise/Gain-Toggles existieren scheinbar an beiden Stellen als
    getrennte Settings-Objekte (unterschiedliche SettingLevel/Storage-Mechanismen je nach
    Codebasis) - unklar, ob sie synchron bleiben oder sich widersprechen können.
  • Lücke: die Video-Qualitätseinstellungen (Auflösung/Framerate/Bitrate/Codec) gibt es
    nur im Call-Widget. Ein Nutzer, der seine Präferenzen vorab einstellen will (ohne
    gerade in einem Call zu sein), findet dafür nichts im Haupt-Client - müsste dafür erst
    einen Call starten/das Widget öffnen.

Mehrwert einer Normalisierung: konsistente, einmal auffindbare Einstellungen statt
zwei getrennter Orte mit potenziell widersprüchlichem Zustand. Nutzer erwarten
Video-Qualitätseinstellungen vermutlich eher im Haupt-Client als im Widget.

Zu klären/umzusetzen (spannt vermutlich beide Repos, ThreadNet-Web + threadnet-call):

  1. Bestandsaufnahme: teilen sich die Audio-Toggles bereits denselben Storage-Mechanismus
    (z.B. beide über Matrix-Account-Data) oder sind das wirklich zwei unabhängige Zustände?
  2. Video-Qualitätseinstellungen: entweder in Element Webs eigenen "Voice & Video"-Tab
    duplizieren (mit Sync zum Widget) oder zumindest einen Link/Verweis vom Haupt-Client zum
    Call-Widget-Setting ergänzen, damit sie auffindbar sind, ohne aktiv in einem Call zu sein.
  3. Grundsatzentscheidung: sollen beide UIs langfristig dieselben Setting-Objekte teilen
    (echte Normalisierung), oder reicht ein Verweis/Link als pragmatischere Zwischenlösung?
Beim Durchgehen der Einstellungs-Oberflächen aufgefallen: Element Web (der Haupt-Client) und Element Call (das eingebettete Widget) haben **getrennte, sich teils überschneidende Settings-UIs** für Audio/Video, ohne erkennbare Synchronisation. **Konkreter Ist-Zustand**: - Element Web hat einen eigenen "Voice & Video"-Tab (`apps/web/src/components/views/settings/tabs/user/VoiceUserSettingsTab.tsx`) mit: Audio-Eingabe-/Ausgabegerät, Video-Eingabegerät, sowie Echo-Cancellation/Noise-Suppression/ Auto-Gain-Toggles. - Element Call (unser Fork, `threadnet-call`) hat im "Video"-Tab (heute erweitert, Issue #8/#11-Kontext) eigene `AudioProcessingSettings` (dieselben drei Audio-Toggles!) UND die `MediaQualitySettings` (Auflösung/Framerate/Bitrate/Codec für Kamera + Screen-Share). - **Überschneidung**: die Echo/Noise/Gain-Toggles existieren scheinbar an beiden Stellen als getrennte Settings-Objekte (unterschiedliche `SettingLevel`/Storage-Mechanismen je nach Codebasis) - unklar, ob sie synchron bleiben oder sich widersprechen können. - **Lücke**: die Video-Qualitätseinstellungen (Auflösung/Framerate/Bitrate/Codec) gibt es **nur** im Call-Widget. Ein Nutzer, der seine Präferenzen vorab einstellen will (ohne gerade in einem Call zu sein), findet dafür nichts im Haupt-Client - müsste dafür erst einen Call starten/das Widget öffnen. **Mehrwert einer Normalisierung**: konsistente, einmal auffindbare Einstellungen statt zwei getrennter Orte mit potenziell widersprüchlichem Zustand. Nutzer erwarten Video-Qualitätseinstellungen vermutlich eher im Haupt-Client als im Widget. **Zu klären/umzusetzen** (spannt vermutlich beide Repos, `ThreadNet-Web` + `threadnet-call`): 1. Bestandsaufnahme: teilen sich die Audio-Toggles bereits denselben Storage-Mechanismus (z.B. beide über Matrix-Account-Data) oder sind das wirklich zwei unabhängige Zustände? 2. Video-Qualitätseinstellungen: entweder in Element Webs eigenen "Voice & Video"-Tab duplizieren (mit Sync zum Widget) oder zumindest einen Link/Verweis vom Haupt-Client zum Call-Widget-Setting ergänzen, damit sie auffindbar sind, ohne aktiv in einem Call zu sein. 3. Grundsatzentscheidung: sollen beide UIs langfristig dieselben Setting-Objekte teilen (echte Normalisierung), oder reicht ein Verweis/Link als pragmatischere Zwischenlösung?
sorb commented 2026-08-01 14:25:48 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/ThreadNet-Web#3 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/ThreadNet-Web#3](https://git.lab/axion1337.chat/ThreadNet-Web/-/issues/3) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
sorb closed this issue 2026-08-01 14:25:50 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/ThreadNet-Web#3