mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
dc66dfb537
meldestelle/docs/99_Journal/2026-04-18_Session_Abschluss_Device-Setup-Focus-Fix.md
StefanMoCoAt 1b20e480f4
Some checks failed
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Failing after 1m0s
Details
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Details
feat: verbessere Device-Setup-UX durch präzise Fokus-Navigation, Plug-and-Play-Optimierungen und Logging-Standardisierung
2026-04-18 22:29:15 +02:00

2.2 KiB
Raw Blame History

Journal-Eintrag: Fokus-Navigation & Keyboard-UX Korrektur (DeviceInitialization)

Datum: 18. April 2026 Status: Abgeschlossen Kontext: Desktop-Zentrale Onboarding

🔍 Problembeschreibung

Der User berichtete von anhaltenden Problemen bei der Tastatur-Navigation (Tabulator- und Enter-Taste) im DeviceInitialization-Screen. Trotz vorangegangener Optimierungen mit ImeAction.Next war der Fokus-Fluss in Compose Desktop unzuverlässig, insbesondere beim Wechsel zwischen MsSettingsField und Standard-OutlinedTextField sowie beim dynamischen Einblenden von Sektionen.

🛠️ Lösung & Implementierung

Um die Navigation absolut deterministisch zu machen, wurde von der automatischen Fokus-Suche auf eine explizite Focus-Requester-Kette umgestellt.

1. Explizite FocusRequester

In DeviceInitializationConfig.jvm.kt wurden FocusRequester für alle Hauptfelder definiert:

  • deviceNameFocus
  • sharedKeyFocus
  • backupPathFocus

2. Harte KeyboardActions

Anstatt sich auf focusManager.moveFocus(FocusDirection.Next) zu verlassen (was bei komplexen Hierarchien fehlschlagen kann), rufen die onNext-Handler nun explizit den requestFocus() des logisch nächsten Feldes auf.

  • Gerätename -> sharedKeyFocus.requestFocus()
  • Sync-Key -> backupPathFocus.requestFocus() (falls Rolle = MASTER)

3. Dialog-Auto-Fokus

Beim Klick auf "+ Client hinzufügen" wird nun mittels LaunchedEffect sofort der Fokus auf das neue Eingabefeld (addClientNameFocus) gesetzt, was einen nahtlosen Übergang ohne Maus-Interaktion ermöglicht.

4. Komponenten-Refactoring

Die MsSettingsField-Komponente wurde erweitert, um den Modifier korrekt an das interne OutlinedTextField durchzureichen, was die Bindung der FocusRequester ermöglichte.

✅ Ergebnis

Die Tastatur-Navigation folgt nun exakt dem fachlichen Workflow:

  1. Gerätename (Enter/Tab) ->
  2. Sync-Key (Enter/Tab) ->
  3. Backup-Pfad (Enter/Tab) ->
  4. Interaktive Elemente (Slider/Buttons)

Dies entspricht dem professionellen Anspruch an eine hocheffiziente Desktop-Anwendung ("Information Density over White Space").

🏗️ [Lead Architect] 🧐 [QA Specialist] 🧹 [Curator]