From 51abcabb27c83251ed3eaac1101c5add16d41354 Mon Sep 17 00:00:00 2001 From: Scarriffle Date: Wed, 30 Sep 2026 17:32:56 +0200 Subject: [PATCH] =?UTF-8?q?Die=20Rechnung=20nachgetragen=20=E2=80=94=20und?= =?UTF-8?q?=20eine=20falsche=20Erkl=C3=A4rung=20zur=C3=BCckgenommen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .../Views/Navigation/FlixyNavigationBar.swift | 8 +++++ Flixy/Views/Navigation/RootView.swift | 32 ++++++++----------- 2 files changed, 22 insertions(+), 18 deletions(-) diff --git a/Flixy/Views/Navigation/FlixyNavigationBar.swift b/Flixy/Views/Navigation/FlixyNavigationBar.swift index fbb85a4..40d87fd 100644 --- a/Flixy/Views/Navigation/FlixyNavigationBar.swift +++ b/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 { diff --git a/Flixy/Views/Navigation/RootView.swift b/Flixy/Views/Navigation/RootView.swift index 3060304..bd69f23 100644 --- a/Flixy/Views/Navigation/RootView.swift +++ b/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 - // Punkt.** + // **Aus dem Fenster, nicht aus dem Layout.** // - // Hier stand `proxy.safeAreaInsets.top`, und daraus wurde eine - // Rückkopplung: der gemessene Rand geht in `topInset`, `topInset` - // geht in einen `safeAreaInset` am Inhalt, und der verändert genau - // den Rand, der gerade gemessen wurde. Das Layout lief danach in - // Runden auf die richtige Grösse zu — jede Runde zweiundsechzig - // Punkte, also genau eine Statusleiste — und blieb auf halbem Weg - // stehen, weil SwiftUI irgendwann aufhört, neu zu rechnen. + // Hier stand `proxy.safeAreaInsets.top` — ein Wert, der beim Drehen + // erst eine Runde später stimmt. Nachgemessen sah man das genau + // einmal: quer war die Seitenleiste zuerst 620,67 Punkte hoch und + // dann 558,67. Die Differenz sind zweiundsechzig, und die kamen von + // `.padding(.top, statusBarHeight)` an der Leiste weiter unten, das + // noch den Wert aus dem Hochformat trug. // - // Sichtbar war das nur im Querformat auf einem grossen iPhone: dort - // ist die Anordnung `regular`, nur dort gibt es den `safeAreaInset`, - // und nur dort ist der Rand vorher und nachher verschieden. Der - // Wurzelbaum war dadurch hundertachtzehn Punkte höher als der - // 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 Umweg über das Layout, das er + // selbst beeinflusst. Die Grösse bleibt der Anlass zum Nachfragen, + // der **Wert** kommt von aussen — und stimmt damit im ersten + // Durchgang. // - // Das Fenster kennt seinen Rand ohne Rückkopplung. Die Grösse bleibt - // der Anlass zum Nachfragen, der **Wert** kommt von aussen. + // **Nicht** die Ursache des Players, der oben und unten hinausging: + // 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 }