Files

T

Thore Cimbal 9d9a87b598 docs: fix theme count and names, stale since 2026-08-06

Said 7 themes, listed Gruvbox Dark and Wal by name - neither exists in element-values.yaml. Actual count verified against the live config: 17. Pointing at management/shared/branding.md as the single place that lists them with colours and light/dark labels instead of duplicating the list here, which is what let this drift in the first place.

2026-08-09 12:00:00 +00:00

6.0 KiB

Raw Blame History

Element Web Customization: Themes, Desktop-Apps, Admin

Status: ✅ Vollständig deployed
Domains: axion1337.chat (Web), /docs/setup (Scripts)

1. Custom Themes (17 Stück, Stand 2026-08-06)

⚠️ Diese Zahl und die Namen waren hier bis 2026-08-09 veraltet (stand auf „7 Stück", nannte u. a. „Gruvbox Dark" und „Wal", die es in der Config so nicht gibt) — korrigiert, nachdem der tatsächliche Bestand gegen element-values.yaml geprüft wurde.

Die Liste mit Farbwerten und hell/dunkel-Kennzeichnung lebt bewusst nur an einer Stelle, um genau dieses Auseinanderlaufen nicht zu wiederholen: management/shared/branding.md (Abschnitt „theme-factory" für die zehn neueren, „Stammschema" für die sieben älteren).

Konfiguration: apps/production/custom-configs/element-values.yaml

Anwendung (User): Settings → Appearance → Colour theme

2. Desktop-Setup-Scripts

System	Datei
Windows	`element-setup-windows.cmd` (Doppelklick)
macOS	`element-setup-macos.command` (Doppelklick)
Linux	`element-setup-linux.sh` (bash)

Was die Scripts tun:

config.json erstellen mit configUrl: "https://axion1337.chat/config.json"
Element installieren (WinGet / Homebrew / apt/dnf/pacman)
Element starten (auto-config laden)

Download: https://axion1337.chat/docs/setup/

3. Element Admin-Panel

URL: https://admin.axion1337.chat

User verwalten
Room durchsuchen
Server-Statistiken

Konfiguration: apps/production/element-server-suite.yaml (ESS Chart)

4. Element Call Fork (Video/Audio-Qualität)

Status: ✅ Deployed (2026-07-28, Closes Issue #8)

Fork: rohana.axion1337.de/sorb/threadnet-call (basiert auf emmick4/element-call:livekit, enthält den noch nicht gemergten Upstream-PR element-hq/element-call#3736 mit config-driven media_quality — kein Custom-Code nötig)
Defaults angehoben: Kamera bis 1440p/60fps (~8 Mbps), Screen-Share 1440p/30fps (~6 Mbps). Startwerte, keine harten Limits — Nutzer können in Settings weiter hochdrehen.
Rauschunterdrückung: clientseitige WebRTC-Standardtoggles (Echo/Noise/Gain), passend zu LiveKits eigener Empfehlung für Mensch-zu-Mensch-Calls. Bewusst kein server-seitiges ML-Noise-Cancellation (siehe docs/TASKS.md Backlog).
Incident (2026-07-28): Erster Versuch mit erzwungenem video_codec: vp9 hat Calls komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt. Vermutete Ursache: LiveKit nutzt für vp9/av1 SVC statt klassischem Simulcast, buildPublishOptions() im Fork setzt aber immer Simulcast-Layer — Code-Fix nötig, bevor vp9 erneut versucht wird (Backlog).
720p-Zwischen-Layer ergänzt (simulcast_layers) — ohne eigene Definition fiel die Übertragung bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p, jetzt sanftere Abstufung über 720p.
H.264 statt VP8 (2026-07-28) — nutzt wie VP8 klassisches Simulcast (kein SVC-Risiko wie bei VP9), zusätzlich auf vielen Geräten (v.a. iOS/Safari) hardwarebeschleunigt. Live verifiziert: 7 von 8 Video-Tracks liefen über H.264, 1 fiel sauber auf den VP8-Backup-Codec zurück (kein Ausfall). Deployed als v0.2.3-elementcall-h264.
Deployt als rohana.axion1337.de/sorb/threadnet-web:v0.2.1-elementcall-noquotavp9 — nur der /app/widgets/element-call/-Ordner im bestehenden v0.1.0-Image ausgetauscht, da ThreadNet-Web einen vorbestehenden Build-Bug hat (siehe unten).
Config live prüfbar: https://axion1337.chat/widgets/element-call/config.json

Update 2026-07-28 (Issue #12) — Full-Rebuild-Blocker behoben: der oben beschriebene Patch-Workaround war nötig, weil ThreadNet-Web komplett neu gebaut nicht funktionierte. Drei Bugs gefixt: (1) 7 Skripte nicht ausführbar committet (644 statt 755, betraf auch die GitHub-Actions-Workflows des Forks), (2) matrix-js-sdk#develop-Pin auf einen veralteten Commit resolved (fehlte src/oidc/authorize.ts) — gepinnt auf d19cb751 (letzter Commit vor dem Rename src/oidc/ → src/oauth/ mit geänderter API), (3) package.json/ webpack.config.ts referenzierten noch upstream @element-hq/element-call-embedded statt unseren Fork. Mit echtem, vollständigem docker build aus frischem Klon verifiziert. Details: Element-Customization Wiki-Seite. Produktivumgebung bleibt beim Patch-Image.

Update 2026-07-28 (später) — Video-Tab statt Developer-Mode: Kamera-/Screen-Share- Qualitätseinstellungen (Auflösung, Framerate, Bitrate, Codec) waren im Upstream-PR #3736 hinter einem "Developer Mode"-Schalter versteckt — in unseren Fork in den regulären "Video"-Settings-Tab verschoben, für alle Nutzer sichtbar. Deutsche Übersetzungen ergänzt (fehlten komplett). Codec-Dropdown auf die tatsächlich von der SFU akzeptierten Codecs beschränkt (VP8/H.264/H.265 — live per SFU-Logs verifiziert; VP9/AV1 wurden von der SFU ohnehin nur transparent auf VP8 zurückgefallen, boten aber keinen echten Effekt).

Update 2026-07-29 — VP9/AV1 live getestet, zurückgerollt (Issue #11): SFU-seitige Codec-Freigabe (matrixRTC.sfu.additional) + Dropdown-Wiederfreischaltung getestet. Trotz echter Auswahl auf Safari und Desktop-Firefox (mit frischem Call-Rejoin) fiel VP9 immer automatisch auf VP8 zurück. SFU-Logs zeigten: die eigene Codec-Freigabe kam serverseitig nie in der aktiven enabledPublishCodecs-Liste an — Ursache nicht abschließend geklärt (möglicher Zusammenhang: sfu.additional ersetzt die Chart-eigene config-overrides.yaml im Config-Merge, statt sie zu ergänzen). Komplett zurückgerollt auf den bekannt funktionierenden 3-Codec-Stand. Details: Issue #11.

Dateien

Datei	Ort
Custom Themes	`element-values.yaml` ConfigMap
Setup-Scripts	`element-web-docs-configmap.yaml`
Docs Server	`element-web-docs-server.yaml` (nginx)
Ingress	`apex-ingress.yaml` (`/docs/setup/` route)

Weitere Details: Siehe Kapitel 4.

6.0 KiB Raw Blame History