dustin/Melo
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity
Files
feature/blur-oeffnen-transition
Melo/ANIMATION_STAND.md
T
Hermes (Server) 4fb6ebddda Stand der Animations-Serie sichern (Projekt-Pause) 
Punkt 1+2 fertig, Punkt 3 (Karaoke-Glow) im Design abgestimmt und
bereit zur Umsetzung, Punkt 4+5 offen. Für nahtlose Wiederaufnahme
nach der Pause.
2026-08-31 17:13:22 +02:00

6.5 KiB
Raw Permalink Blame History

Animations-Serie (HyperOS-inspiriert) — Stand bei Pause

Projekt pausiert am 2026-08-31. Dieses Dokument fasst zusammen, wo die Animations-Serie steht, damit eine neue Session nahtlos weitermachen kann.

Herkunft

Ausgangspunkt: Analyse-Auftrag zur Xiaomi-Musik-App/HyperOS-Design-Sprache, daraus ein Bericht mit 5 Animations-Empfehlungen für Mello, priorisiert nach Aufwand/Wirkung. Punkte 1+2 sind umgesetzt, Punkt 3 ist im Design fertig abgestimmt, aber noch nicht implementiert. Punkte 4+5 sind offen.

Status je Punkt

✅ Punkt 1 — Staggered List-Enter-Animation (fertig, gemerged-bereit)

EinblendItem-Widget (lib/shared/einblend_item.dart), eingebunden in song_list.dart/artist_list.dart. Fertig, getestet, committet+gepusht auf Branch fix/tinker-feedback (im Worktree ~/mello-dev/app). Noch nicht in main gemerged.

✅ Punkt 2 — Vollbild-Player als Live-Blur-Overlay (fertig, gepusht)

NowPlayingScreen von Navigator-Route zu persistentem Overlay in HomeShell umgebaut (PlayerExpansionController, Live-Blur/Cover-Interpolation während der Wischgeste). Vollständig umgesetzt (10-Task-Plan + 3 Bugfixes aus dem finalen Review), 626 Tests grün, flutter analyze sauber.

  • Branch: feature/blur-oeffnen-transition (Basis: fix/tinker-feedback)
  • Worktree: ~/mello-dev/worktrees/blur-transition (dieser hier)
  • Gepusht, PR noch nicht erstellt/gemerged: https://git.baka-net.de/dustin/Melo/pulls/new/feature/blur-oeffnen-transition
  • Spec: docs/superpowers/specs/2026-08-29-blur-oeffnen-transition-design.md
  • Plan: docs/superpowers/plans/2026-08-29-blur-oeffnen-transition.md
  • Durchlief ein Adversarial-Review-Panel (Budget-Mode, 3 Reviewer) vor der Umsetzung — fand einen echten P0 (falsches AnimatedBuilder.child-Muster). Ein zweites Review NACH der Umsetzung, vor dem Push, fand nochmal 3 echte Bugs (Provider-Scope-Crash bei per Navigator.push geöffneten Screens, RenderFlex-Overflow während der Öffnen-Geste, asymmetrischer dragEnd-Bug) — alle behoben, siehe Commit-History auf dem Branch.
  • Wichtige Lektion für künftige Overlay-artige Provider: Ein ChangeNotifierProvider, der nur innerhalb eines Screens (nicht oberhalb des Navigators) bereitgestellt wird, ist für per Navigator.push geöffnete Screens unsichtbar (die sind Geschwister im selben Navigator/Overlay, keine Nachfahren). PlayerExpansionController sitzt deshalb jetzt in MeloApps MultiProvider (lib/main.dart), nicht in HomeShell.

🔜 Punkt 3 — Karaoke-Glow in der Songtext-Ansicht (Design fertig, NICHT umgesetzt)

Nächster Schritt beim Wiederaufnehmen. Brainstorming abgeschlossen, Design mit Dustin abgestimmt und freigegeben — direkt umsetzbar ohne erneute Rückfrage:

  • Datei: lib/player/now_playing_screen.dart, Klasse _Mitlaufend (aktuell Zeile ~759-810 auf diesem Branch), nur der AnimatedDefaultTextStyle darin (~Zeile 793-800).
  • Änderung:
    • style: bekommt zusätzlich shadows:, animiert über den bestehenden AnimatedDefaultTextStyle-Mechanismus (kein neuer Controller nötig, TextStyle.lerp interpoliert shadows automatisch):
      • Inaktive Zeile: shadows: const []
      • Aktive Zeile: shadows: [Shadow(color: MeloTheme.red.withValues(alpha: 0.55), blurRadius: 10)]
    • Textfarbe bleibt wie bisher (Colors.white/MeloTheme.text3) — bewusst kein rot eingefärbter Text (Kontrast/Lesbarkeit auf dunklem Grund), stattdessen weißer Text mit rotem Glow dahinter ("Spotlight"-Effekt). Diese Frage wurde Dustin explizit gestellt, Antwort: Glow statt Rot-Einfärbung.
    • duration: von MeloMotion.fast (120ms) auf MeloMotion.normal (220ms) korrigiert — laut theme.darts eigener Doku ist fast für Touch-Feedback gedacht, ein Zeilenwechsel ist aber ein Inhalts-Wechsel (normal). Passt auch besser zum "fließenden" Karaoke-Gefühl.
  • Testing: bestehenden Widget-Test für _Mitlaufend/_LyricsSheet (falls vorhanden) auf den neuen shadows-Wert prüfen; neuer Test bestätigt aktive Zeile hat MeloTheme.red-farbenen Schatten, inaktive shadows: [].
  • Workflow ab hier: TDD-Umsetzung (bounded, kein Plan-Dokument nötig) → @code-reviewer-Skill (/code-review) vor dem Commit → committen+pushen auf feature/blur-oeffnen-transition (baut direkt auf Punkt 2 auf, gleiche Datei).

⬜ Punkt 4 — Advanced-Blur-Kopplung am Farbverlauf-Hintergrund (offen)

Aus dem ursprünglichen Bericht: _CoverGrunds Farbverlauf-Hintergrund zusätzlich leicht auf Wisch-Distanz reagieren lassen (Blur-Radius steigt beim Öffnen/Schließen). Noch nicht brainstormed/geplant. Mittlerer Aufwand, baut auf Punkt 2s progress-Wert auf (PlayerExpansionController).

⬜ Punkt 5 — Equalizer-Visualizer (offen, niedrige Priorität)

Spektrum-Visualizer in equalizer_screen.dart, analog zu Xiaomis Musik-App. Braucht Audio-Frequenzanalyse (aktuell nicht vorhanden) — deutlich höherer Aufwand, im ursprünglichen Bericht selbst als "nice-to-have, niedrige Priorität" eingestuft. Noch nicht brainstormed.

Wichtige Rahmenbedingungen fürs Wiederaufnehmen

  • Worktree-Disziplin: ~/mello-dev/app ist ein GETEILTER Worktree (andere Session, aktuell "Hermes"/mello-dev-80, arbeitet dort an YouTube-Gast-Zugang o.ä.) — vor jedem git-Befehl dort git status prüfen, nicht blind committen. Für neue, eigenständige Punkte (4/5) einen eigenen Worktree anlegen (git worktree add -b <branch> ~/mello-dev/worktrees/<name> <basis>), wie bei Punkt 2 geschehen.
  • Flutter-Binary: IMMER /home/dustin/development/flutter/bin/flutter verwenden, NICHT das über PATH auffindbare Snap-flutter — letzteres wirft "Invalid kernel binary format version" (Toolchain-Mismatch mit den gecachten Native-Hooks).
  • Pläne/fertige Designs gehen an Hermes (Peer-Session mello-dev-80), nicht direkt an Dustin im Chat — Hermes bespricht mit Dustin und gibt dann die Freigabe zurück. Ausnahme: reine Werkzeug-/Ziel-Klärungen.
  • Skill-Workflow laut Projekt-CLAUDE.md: brainstorming → planning (nur bei Architectural-Einstufung) → agent-review-panel → TDD → Debugging. Für Punkt 2 wurde ein Budget-Mode-Adversarial-Panel genutzt (3 Reviewer: Code-Quality-Auditor, Feasibility-Analyst, Devil's Advocate + Synthese ohne separaten Richter-Agent, da die Befunde stark konvergent/eindeutig waren) — hat sich gelohnt, fand echte Bugs vor UND nach der Umsetzung.
  • Subagent-Profile aktiv nutzen: @melo-specialist für alle App-Änderungen (nicht general-purpose).
Reference in New Issue View Git Blame Copy Permalink