Reine Umbenennung, kein Verhalten geändert — bewusst als eigener Commit, damit „umbenannt" und „umgebaut" im Nachhinein auseinanderzuhalten sind. 712 mal `Flixy`, 778 mal `flixy`, 7 mal `FLIXY` in 169 Dateien, dazu 25 Pfade. Ziele: `Halo`, `HaloTV`, `HaloTopShelf`, `HaloUITests`, `HaloKit` mit `HaloDesign`, `HaloDownloads`, `HaloPlayback` und `HaloProbe`. `MediaKit`, `JellyfinKit` und `DownloadWidget` tragen den Namen nicht und bleiben. `docs/superpowers/specs/` ist ausgenommen. Datierte Entwurfsdokumente sind ein Protokoll getroffener Entscheidungen; sie nachträglich umzuschreiben hiesse, die Vergangenheit zu glätten. **Die Bundle-ID wandert mit** — ausdrücklich so gewollt, mit bekanntem Preis: `com.scarriffleservices.halo` ist für iOS eine *andere* App. Die installierte Fassung bleibt daneben stehen, mit Downloads und Anmeldung in ihrem Container; Halo startet leer. Einmal neu anmelden, heruntergeladene Folgen einmal neu laden. Dasselbe gilt für die App-Gruppe, die sich TV-App und Top Shelf teilen. **Eine Folge davon, die beim Entscheiden noch nicht auf dem Tisch lag:** der Aufräumschritt aus dem vorigen Commit kommt an die alten Plex-Token nicht mehr heran. Der Schlüsselbund grenzt nach Team und Bundle-Kennung ab — was unter `…flixy` liegt, ist für `…halo` unerreichbar. Erledigt wird es trotzdem, nur anders: **die alte App löschen.** iOS räumt deren Schlüsselbund-Einträge beim Deinstallieren mit ab. Der Code bleibt stehen, weil er für jeden Stand vor dieser Umbenennung richtig ist und im Jahr einen Startvergleich kostet. Die Projektdatei ist aus `project.yml` neu erzeugt, der alte Ordner gelöscht statt umbenannt — sie steht ohnehin nicht im Repo. Das Verzeichnis des Repos selbst heißt weiter `Flixy`; das umzubenennen ist ein Handgriff ausserhalb des Projekts. 368 Tests grün. iOS und tvOS bauen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
38 lines
1.7 KiB
Swift
38 lines
1.7 KiB
Swift
import Foundation
|
|
|
|
/// Wann nachgeladen wird.
|
|
///
|
|
/// **Nicht „die letzten fünf".** So stand es bisher, und zwei Dinge daran
|
|
/// gehen schief. Erstens ist das auf einem Raster aus sechs Spalten nicht
|
|
/// einmal eine Zeile: wer dort ankommt, wartet trotzdem. Zweitens — und das
|
|
/// ist der eigentliche Fehler — hing es am **Erscheinen** der Kachel. Beim
|
|
/// ersten Zeichnen erscheinen alle sechzig gleichzeitig, auch die letzten
|
|
/// fünf; das Nachladen lief also sofort los statt beim Scrollen.
|
|
///
|
|
/// Gemessen wird deshalb in **Zeilen**, und der Auslöser ist auf dem
|
|
/// Fernseher der Fokus statt des Erscheinens. Auf einem breiten Raster ist
|
|
/// das nicht Feinschliff: dort sind sechs Kacheln eine Zeile, und mit der
|
|
/// alten Regel wäre schon die erste Bildschirmseite „fast am Ende".
|
|
public struct PagingWindow: Sendable, Equatable {
|
|
/// Wie viele Kacheln nebeneinander stehen.
|
|
public let columns: Int
|
|
/// Wie viele Zeilen Vorlauf gewünscht sind.
|
|
public let rowsAhead: Int
|
|
|
|
public init(columns: Int, rowsAhead: Int = 2) {
|
|
self.columns = columns
|
|
self.rowsAhead = rowsAhead
|
|
}
|
|
|
|
/// - Parameter focusedIndex: Wo der Fokus gerade steht.
|
|
/// - Parameter loaded: Wie viele Einträge schon dastehen.
|
|
/// - Parameter total: Wie viele der Server insgesamt meldet.
|
|
public func shouldLoad(focusedIndex: Int, loaded: Int, total: Int) -> Bool {
|
|
// `columns <= 0` ist keine sinnvolle Frage, aber eine mögliche: ein
|
|
// Raster kennt seine Spaltenzahl erst nach dem ersten Zeichnen. Null
|
|
// zurückzugeben ist richtiger, als durch null zu teilen.
|
|
guard columns > 0, loaded > 0, loaded < total else { return false }
|
|
return focusedIndex >= loaded - columns * rowsAhead
|
|
}
|
|
}
|