Die Rechnung nachgetragen — und eine falsche Erklärung zurückgenommen

Eine unabhängige Gegenprüfung (zweiunddreissig Agenten, jede Behauptung
von Skeptikern angegriffen) bestätigt die Ursache und rechnet alle vier
gemessenen Zahlen nach:

    scrollbarer Teil  421,0   (8 Zeilen à 36,33 + Überschrift 22,33
                               + 8 Zwischenräume à 12 + 12 unten)
    starrer Rest      137,6   (Kopfzeile 48,33 + Trenner 1
                               + Kontozeile 64,27 + 2 × 12 aussen)
    zusammen          558,6   gemessen 558,67
    zentriert         (420 − 558,67) / 2 = −69,335   gemessen −69,33

Die Rechnung steht jetzt im Quelltext, damit beim nächsten Eintrag in der
Leiste jemand nachsehen kann, wie viel Luft noch ist: starr bleiben 137,6
von 420.

**Und eine Berichtigung.** Ich hatte den Zwischenwert 620,67 einer
Rückkopplung zugeschrieben — gemessener Rand geht über `topInset` in
einen `safeAreaInset` und verändert den Rand. Das stimmt nicht. Die
Differenz von zweiundsechzig kommt schlicht aus
`.padding(.top, statusBarHeight)` an der Seitenleiste, das während der
Drehung noch den Hochformatwert trug.

Die Umstellung auf den Fensterwert bleibt richtig und nützlich — sie
spart eine Layoutrunde. Sie war nur nicht die Reparatur, und der
Kommentar sagte etwas anderes. Ein Kommentar, der einen falschen
Mechanismus behauptet, ist schlimmer als keiner: er schickt den nächsten
in die falsche Richtung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Flixy/Views/Navigation/FlixyNavigationBar.swift

@@ -122,6 +122,14 @@ struct FlixySidebar: View {
             // `basedOnSize`: es wird nur gescrollt, wenn es nötig ist. Wo die
             // Einträge passen, sieht man keinen Unterschied.
             //
+            // Nachgerechnet, damit es nicht wiederkommt: scrollbarer Teil
+            // 421 Punkte (acht Zeilen à 36,33, eine Gruppenüberschrift
+            // 22,33, acht Zwischenräume à 12, unten 12), starrer Rest
+            // 137,6 (Kopfzeile 48,33, Trenner 1, Kontozeile 64,27, aussen
+            // zweimal 12). Zusammen 558,6 — gemessen wurden 558,67. Nach dem
+            // Umbau bleiben 137,6 starr, bei 420 verfügbaren: auch mit
+            // doppelt so vielen Mediatheken passt das.
+            //
             // Beim Bearbeiten braucht es eine Liste — nur die bringt das
             // Ziehen zum Umsortieren mit, und die scrollt von sich aus.
             if isEditing {

Flixy/Views/Navigation/RootView.swift

@@ -113,27 +113,23 @@ struct RootView: View {
         }
         .background(Color.flixyCanvas)
         .environment(topChrome)
-        // **Aus dem Fenster, nicht aus dem Layout — und das ist der ganze
+        // **Aus dem Fenster, nicht aus dem Layout.**
-        // Punkt.**
         //
-        // Hier stand `proxy.safeAreaInsets.top`, und daraus wurde eine
+        // Hier stand `proxy.safeAreaInsets.top` — ein Wert, der beim Drehen
-        // Rückkopplung: der gemessene Rand geht in `topInset`, `topInset`
+        // erst eine Runde später stimmt. Nachgemessen sah man das genau
-        // geht in einen `safeAreaInset` am Inhalt, und der verändert genau
+        // einmal: quer war die Seitenleiste zuerst 620,67 Punkte hoch und
-        // den Rand, der gerade gemessen wurde. Das Layout lief danach in
+        // dann 558,67. Die Differenz sind zweiundsechzig, und die kamen von
-        // Runden auf die richtige Grösse zu — jede Runde zweiundsechzig
+        // `.padding(.top, statusBarHeight)` an der Leiste weiter unten, das
-        // Punkte, also genau eine Statusleiste — und blieb auf halbem Weg
+        // noch den Wert aus dem Hochformat trug.
-        // stehen, weil SwiftUI irgendwann aufhört, neu zu rechnen.
         //
-        // Sichtbar war das nur im Querformat auf einem grossen iPhone: dort
+        // Das Fenster kennt seinen Rand ohne Umweg über das Layout, das er
-        // ist die Anordnung `regular`, nur dort gibt es den `safeAreaInset`,
+        // selbst beeinflusst. Die Grösse bleibt der Anlass zum Nachfragen,
-        // und nur dort ist der Rand vorher und nachher verschieden. Der
+        // der **Wert** kommt von aussen — und stimmt damit im ersten
-        // Wurzelbaum war dadurch hundertachtzehn Punkte höher als der
+        // Durchgang.
-        // Bildschirm und begann neunundsechzig darüber — und der Player, der
-        // als Überlagerung darin liegt, ging oben und unten hinaus. Genau so
-        // verschwanden Kopfzeile und Zeitangaben.
         //
-        // Das Fenster kennt seinen Rand ohne Rückkopplung. Die Grösse bleibt
+        // **Nicht** die Ursache des Players, der oben und unten hinausging:
-        // der Anlass zum Nachfragen, der **Wert** kommt von aussen.
+        // das war die Seitenleiste selbst, siehe `FlixySidebar`. Diese Zeile
+        // spart eine Layoutrunde, mehr nicht.
         .onGeometryChange(for: CGSize.self) { proxy in
             proxy.size
         } action: { _ in statusBarHeight = ScreenSafeArea.current.top }