Meetings, die man endlich wiederfindet: das Timeline-Release

Bis Januar 2026 hatten GeekBye-Nutzer ein Historien-Problem. Die App zeichnete ihre Meetings brav auf und analysierte sie — und legte sie dann in einem Dropdown ab. Ein Dropdown ist in Ordnung für drei Einträge. Bei Meeting fünfzehn war „dieses Interview von letztem Dienstag" eine archäologische Expedition durch identisch aussehende Zeilen. v1.7.3 — 64 Commits zwischen Mitte Dezember und dem 16. Januar — ist das Release, in dem Meetings zu etwas wurden, das man endlich wiederfindet.

(Eine buchhalterische Anmerkung, weil die Git-Historie ehrlich ist, auch wenn Versionsnummern es nicht sind: es gibt keinen v1.7.2-Release-Tag. Die Version wurde erhöht, aber der nächste Tag, der auslieferte, war v1.7.3 — die Windows-Fixes der v1.7.2-Ära fuhren also in diesem Release mit.)

Vom Dropdown zur Timeline

Die Schlagzeilen-Änderung ist ein einziger Pull Request: 12 Dateien, +640 Zeilen, das meiste davon eine neue 381-Zeilen-Komponente MeetingsTimeline. Das Dropdown wurde zu einer scrollbaren Timeline aus Meeting-Karten, gruppiert in vier Buckets — Today, Yesterday, This Week, Older (heute, gestern, diese Woche, älter) — mit Datumsangaben, wie ein Mensch sie sagen würde: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM für diese Woche und Jan 5, 2:30 PM darüber hinaus. Cmd/Ctrl+K fokussiert ein Suchfeld, das nach Titel filtert. Die Meeting-Detailansicht wurde eine echte Navigationsseite, sodass die Zurück- und Vorwärts-Buttons der Navbar endlich etwas bedeuten, und der Breadcrumb las nicht mehr „Meetings / Meeting", sondern „Meetings / Interview with John" (abgeschnitten mit Auslassungspunkten, weil immer jemand ein Meeting wie einen Roman benennt).

Zwei kleine Quality-of-Life-Stücke kamen mit: ein Löschen-Button in der Meeting-Ansicht (der einen nach dem Löschen zurück zur Timeline navigiert, statt einen auf einer toten Seite stranden zu lassen), und die Auto-Navigation — wenn eine Listening-Session mit echtem Transkript-Inhalt endet, öffnet sich das Dashboard direkt auf der Detailseite dieses Meetings. Anruf beenden, Meeting sehen. Sessions, die leer enden, werden stillschweigend gelöscht, statt die Timeline zuzumüllen.

Das Race, das man sich mit besserer Navigation einhandelt

Hier kommt der Teil, den der Changelog nicht erzählt. Die alte Meeting-Liste hatte eine Angewohnheit: bei jedem Laden wählte sie automatisch die neueste Session aus. Harmlos, solange die Liste ein Dropdown war, das man kaum anfasste. Fatal in dem Moment, in dem Meetings eine Seite wurden, auf der man navigiert: Meeting Nr. 5 anklicken, ein Hintergrund-Refetch wird fertig, und die Liste wählt hilfsbereit das neueste Meeting aus — und überschreibt die Wahl, die man vor zwei Sekunden getroffen hat. Der Fix war kein cleverer Guard; es war das komplette Löschen des Auto-Select. Jede Liste, die im Namen des Nutzers Dinge auswählt, wird irgendwann gegen den Nutzer kämpfen.

Das Entfernen legte das zweite Race frei. Die Auto-Navigation springt zu einem Meeting, sobald seine Session endet — was sein kann, bevor diese Session fertig in die lokale SQLite-Datenbank geschrieben hat. Navigiert man zu schnell, kommt man bei einem Meeting an, das noch nicht existiert. Der ausgelieferte Fix ist eine 500-Millisekunden-Verzögerung vor dem Laden der Sessions beim Ankommen in der Detailansicht, und der Navigations-Handler trägt seine eigenen Absicherungen — auf das did-finish-load des Fensters warten plus 100ms, wenn das Dashboard gerade erst erzeugt wurde, 50ms, wenn es schon offen war. Unsere Lesart: die Session-Ende-Navigation überquert drei Timing-Domänen — den Datenbank-Schreibvorgang, das Fenster-Laden und das React-Mounting — und jede bekam ihre eigene kleine Verzögerung. Es funktioniert, und wir sagen es geradeheraus: ein Stapel magischer Zahlen ist ehrliche Schulden, kein Sieg.

Der Screenshot, der älter ist als sein eigenes Meeting

Eine weitere Annahme starb in diesem Release: „Screenshots gehören genau dann zu einer Session, wenn sie währenddessen aufgenommen wurden." Vollkommen logisch. Falsch. Echte Nutzer drücken Cmd+H auf der Stellenanzeige, der Agenda, dem Code, über den sie gleich sprechen — bevor sie Start drücken. Der Report-Tab ordnete Screenshots dem Zeitfenster der Session strikt zu, also verschwanden diese Vorbereitungs-Screenshots aus genau dem Report, für den sie aufgenommen worden waren. Der Fix hat das Matching-Fenster um 60 Sekunden vor Session-Beginn erweitert. (Die Zeitfenster-Maschinerie selbst ist älter — sie war still in v1.6.15 ausgeliefert worden; der Beitrag von v1.7.3 ist, ihr beizubringen, dass Meetings ein bisschen vor ihrem Beginn beginnen.)

Fünf Fixes in achtundzwanzig Minuten

Die Kriegsgeschichte dieses Release steckt gar nicht in der Timeline — sie steckt im Windows-Onboarding-Overlay, und sie ist eine lehrbuchhafte „Fix den Fix"-Kette: fünf Commits zwischen 10:50 und 11:18 am selben Morgen.

GeekByes Hauptfenster nutzt Maus-Passthrough — einen Hook, der Electrons setIgnoreMouseEvents bei jeder Mausbewegung umschaltet, damit Klicks durch transparente Bereiche hindurchfallen. Während des Onboardings unter Windows kämpfte dieser Hook gegen das Tutorial-Overlay, und an dem Schritt, an dem das Dashboard-Fenster erscheint, fror die App ein. Fix eins: den Hook nichts tun lassen, solange das Onboarding aktiv ist. Frieden durch Abrüstung.

Nur dass jetzt die Onboarding-Buttons nicht mehr reagierten, weil das Event-Forwarding die Klicks an das Dashboard-Fenster unter dem Overlay verschickte. Fixes zwei und drei fummelten pro Wizard an forward: false herum. Dann kam der Commit, der die eigentliche Ursache fand: wenn das Dashboard-Fenster öffnet, setzt sein Drag-Handler das Hauptfenster in den Click-Through-Modus zurück — und der erste Fix hatte den Passthrough-Hook passiv gemacht, was hieß: es war nichts mehr übrig, das die Störung korrigieren konnte. Der echte Fix drehte die Strategie um: der Hook setzt während des Onboardings jetzt bei jeder Mausbewegung aktiv setIgnoreMouseEvents(false) durch, gerade weil externer Code es jederzeit zurücksetzen kann. Er löschte außerdem 75 Zeilen der früheren Pro-Wizard-Workarounds.

Und selbst dann gab es einen fünften Commit, weil den Input-Krieg zu gewinnen nicht heißt, den Z-Order-Krieg zu gewinnen: Overlay und Dashboard saßen auf demselben Always-on-top-Level, und Windows hebt das Fenster an, das den Fokus bekommt. Das Overlay zog auf ein höheres Fenster-Level und hebt sich nach dem Erscheinen des Dashboards mit Verzögerung selbst wieder an. Den Bogen sollte man sich merken: ein passiver Fix, der den einzigen Verteidiger entwaffnet, ist schlimmer als der ursprüngliche Kampf.

Drei Dinge, die uns dieses Release lehrte

1. Navigations-Upgrades bringen State-Bugs an die Oberfläche. Das Auto-Select-Race existierte schon vor v1.7.3; ein Dropdown ließ es einen nur nie spüren. In dem Moment, in dem Meetings eine Seite wurden, auf der man bewusst navigiert, wurde jedes Stück Code, das Dinge für einen auswählte, zum Bug.
2. Zeitgrenzen um Nutzerabsicht brauchen Spiel. Sessions, Aufnahmen, Reports — Nutzer handeln etwas vor und etwas nach dem offiziellen Fenster der Maschine. Der 60-Sekunden-Screenshot-Puffer ist eine Zeile, die widerspiegelt, wie Menschen sich tatsächlich verhalten.
3. Mach deinen korrigierenden Code niemals passiv. Der Windows-Freeze brauchte fünf Fixes, weil Fix eins den einzigen Mechanismus abschaltete, der externe Störungen kontern konnte. Wenn anderer Code deine Invariante jederzeit brechen kann, ist es dein Job, sie kontinuierlich durchzusetzen, nicht dich zurückzuziehen.

Für das vorige Kapitel der v1-Geschichte — zwei gebrandete Apps aus dieser einen Codebasis bauen — siehe eine Codebasis, zwei Apps: White-Label ohne Fork (v1.7.1); und für den ganzen Bogen, die Anatomie, Software bis zur Perfektion auszuliefern.