dustin/Melo
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Hauptmenue wieder deutlich sichtbar

Browse Source 
Entwarnung vorweg: es fehlt nichts. Alle vier Bereiche (Meine Musik,
Online, Suchen, Favoriten) standen durchgehend in der Bottom-Nav;
lib/main.dart wurde von der UI-Politur gar nicht angefasst.

Aber die Politur hatte das Menue abgeschwaecht — zwei eigene Fehler:
- selectedLabelStyle/unselectedLabelStyle bekamen beide fontSize 12. Damit
  verlor der aktive Eintrag den Groessenunterschied (Flutter-Vorgabe 14 zu
  12), an dem man erkennt, wo man ist. Jetzt keine fontSize mehr.
- unselectedItemColor stand auf text3 (Beiwerk-Stufe). Ein Hauptmenue ist
  kein Beiwerk -> text2.

Zusaetzlich deutlicher: Haarlinie ueber der Leiste (auf Schwarz ging sie
sonst im Inhalt auf), gefuellte Symbole fuer den aktiven Bereich (zweites
Merkmal neben der Farbe) und fetterer aktiver Eintrag.

Neu: test/hauptmenue_test.dart — prueft Vorhandensein, Sichtbarkeit auf dem
Bildschirm, Position am unteren Rand, Wechsel per Tipp und die Abhebung des
aktiven Bereichs. Damit kann keine weitere Politur das Menue unbemerkt
abschwaechen.

Nebenbei eine Test-Falle geloest: await db.close() nach einem tester.tap
laesst den Lauf unbegrenzt haengen (drift plant eine Aufraeum-Aufgabe ein,
die der Test-Rahmen nicht mehr abarbeitet). Rezept im Test dokumentiert.
Beim bekannten Haenger in song_detail_sheet_test.dart hilft es NICHT —
gegengeprueft und als eigene Ursache im BACKLOG vermerkt.

328 Tests gruen (10 neue, 1 uebersprungen), flutter analyze ohne Befund.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FpPu4nuKjKKeX1RpdDeX81
This commit is contained in:
Hermes (Server)
2026-08-21 14:13:11 +02:00
co-authored by Claude Opus 5
parent 1547f43099
commit 5b6fa949a9
5 changed files with 281 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BACKLOG.md
+11
View File
@@ -28,8 +28,19 @@ den nächsten Bibliotheks-Scan damit überlebt.
| `http.runWithClient` erreicht den State im Modal-Sheet nicht | ❌ widerlegt — eigene Sonde zeigt `MockClient` auch im Sheet |
| drift unter `testWidgets` blockiert (fehlendes `runAsync`) | ❌ widerlegt — `upsertSongs` + `watchSongs().first` laufen durch |
| Einer der Provider blockiert `pumpWidget` | ❌ widerlegt — `MeloDb`, `CategoryService`, `AppSettings` einzeln geprüft |
| `db.close()` im Teardown (der Hänger aus `hauptmenue_test.dart`) | ❌ widerlegt — Entfernen ändert nichts, siehe unten |
| Zusammenspiel `showModalBottomSheet` + Providerbaum | ⏳ offen — der Hänger tritt zwischen `pumpWidget` und dem ersten `tap` auf |
**Nicht die Ursache (2026-08-21 geprüft):** In `hauptmenue_test.dart` trat ein
Hänger mit derselben Signatur auf. Dort war die Ursache `await db.close()`
nach einem `tester.tap` — drift plant beim Schließen eine Aufräum-Aufgabe
ein, die der Test-Rahmen nicht mehr abarbeitet. Das Rezept dagegen:
Dienste per `.value` bereitstellen (der Baum darf sie nicht schließen), am
Testende `pumpWidget(SizedBox())` + `pump(Duration(milliseconds: 1))`, und
auf `db.close()` verzichten. **Bei `song_detail_sheet_test.dart` hilft genau
das nicht** — dort wurde es angewandt und der Test hängt weiter. Die beiden
Hänger haben also unterschiedliche Ursachen.
**Nächster Schritt:** Den Testkörper schrittweise abspecken (Providerbaum
minimieren, Sheet durch eine normale Route ersetzen) bis der Hänger
verschwindet — die letzte entfernte Zutat ist die Ursache. Ein