# Fensterkonzept

Die Anwendung ist nach dem Login fensterbasiert. Das Dashboard bleibt die
Hauptfläche und zeigt Status, Live-Verbindung und zusammenfassende Daten. Alle
fachlichen Arbeitsbereiche öffnen als eigene Fenster.

## Grundregeln

- Vor dem Login sind nur Login und Registrierung sichtbar.
- Nach dem Login bleibt das Dashboard die Basisansicht.
- Navigationseinträge außer Dashboard öffnen ein Fenster.
- Ein bereits geöffnetes Fenster wird fokussiert, nicht doppelt geöffnet.
- Fenster können geschlossen und später erneut geöffnet werden.
- Fenster behalten pro Benutzer Position, Größe und Reihenfolge, soweit der
  jeweilige Client das technisch unterstützt.
- Offene Listenfenster müssen auf Live-Events reagieren und ihre Daten
  aktualisieren oder als veraltet markieren.

## Einheitliche Fensteraktionen

- `Öffnen`: Fenster wird erzeugt oder, falls vorhanden, fokussiert.
- `Fokussieren`: Fenster erhält die höchste Z-Reihenfolge.
- `Schließen`: Fenster wird aus der Arbeitsfläche entfernt.
- `Verschieben`: Fensterposition wird geändert.
- `Größe ändern`: Fensterabmessungen werden geändert.
- `Aktualisieren`: Fenster lädt seine Daten neu oder reagiert auf ein
  Backend-Event.

## Webclient

- Fenster werden über der Dashboard-Fläche dargestellt.
- Position und Größe sind per Maus oder Pointer veränderbar.
- Fensterstatus wird im `localStorage` pro Benutzer gespeichert.
- Wiederherstellung erfolgt nach Login oder Reload.

## Desktopclient

- Fenster verwenden native `egui::Window`-Instanzen.
- Benutzerrechte, Firmendaten und Freischaltungen sind als Fenster umgesetzt.
- Weitere fachliche Module folgen demselben Muster.

## Live-Updates

Backend-Änderungen erzeugen Events über die bestehende Socket-Verbindung. Clients
verwenden diese Events, um offene Fenster zu aktualisieren oder deren Status auf
`Aktualisiert` zu setzen.

Für Phase 2 genügt ein gemeinsamer Live-Event-Store pro Client. Fachliche
Module können später gezielt nach Entity-Typ filtern.

## Parallelbearbeitung und Konflikte

- Schreibvorgänge laufen immer über das Backend.
- Das Backend entscheidet final über Berechtigungen und Datenstand.
- Bei konkurrierenden Änderungen wird zunächst eine frische Liste geladen.
- Für spätere fachliche Datensätze wird ein Versionsfeld oder `updated_at`
  benötigt, damit Konflikte vor dem Speichern erkennbar sind.