Meetings die je écht terugvindt: de timeline-release
GeekBye v1.7.3 verving de meetings-dropdown door een echte tijdlijn — menselijke datums, zoeken, een breadcrumb die vertelt in welke meeting je zit. Daaronder: een auto-select-race, een screenshot die ouder is dan zijn eigen meeting, en vijf Windows-fixes in achtentwintig minuten.
Tegen januari 2026 hadden GeekBye-gebruikers een geschiedenisprobleem. De app nam hun meetings prima op en analyseerde ze netjes — om ze vervolgens weg te bergen in een dropdown. Een dropdown is prima voor drie items. Bij meeting vijftien was "dat interview van afgelopen dinsdag" een archeologische expeditie door identiek ogende rijen. v1.7.3 — 64 commits tussen half december en 16 januari — is de release waarin meetings iets werden dat je daadwerkelijk kon terugvinden.
(Eén boekhoudkundige noot, want de git-history is eerlijk ook als versienummers dat niet zijn: er bestaat geen v1.7.2-releasetag. De versie werd wel opgehoogd, maar de eerstvolgende tag die shipte was v1.7.3, dus de Windows-fixes uit het v1.7.2-tijdperk liftten mee in deze release.)
Van dropdown naar tijdlijn
De hoofdwijziging is één pull request: 12 files, +640 regels, waarvan het merendeel een nieuwe MeetingsTimeline-component van 381 regels. De dropdown werd een scrollbare tijdlijn van meetingkaarten, gegroepeerd in vier buckets — Today, Yesterday, This Week, Older — met datums zoals een mens ze zou zeggen: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM voor deze week en Jan 5, 2:30 PM daarbuiten. Cmd/Ctrl+K focust een zoekveld dat op titel filtert. De meeting-detailweergave werd een echte navigatiepagina, dus de terug- en vooruitknoppen in de navbar betekenen eindelijk iets, en de breadcrumb las niet langer "Meetings / Meeting" maar "Meetings / Interview with John" (afgekapt met een ellipsis, want iemand geeft zijn meeting altijd een titel als een roman).
Twee kleine quality-of-life-dingen shipten mee: een verwijderknop binnen de meetingweergave (die je na het verwijderen terug naar de tijdlijn navigeert in plaats van je op een dode pagina achter te laten), en auto-navigatie — wanneer een luistersessie eindigt met daadwerkelijke transcriptinhoud, opent het dashboard direct op de detailpagina van die meeting. Beëindig het gesprek, zie de meeting. Sessies die leeg eindigen worden stilletjes verwijderd in plaats van de tijdlijn te vervuilen.
De race die je creëert door navigatie te verbeteren
Hier komt het deel dat de changelog je niet vertelt. De oude meetinglijst had een gewoonte: bij elke load selecteerde hij automatisch de nieuwste sessie. Onschuldig toen de lijst een dropdown was die je zelden aanraakte. Fataal op het moment dat meetings een pagina werden waar je naartoe navigeert: klik op meeting #5, een achtergrond-refetch rondt af, en de lijst selecteert behulpzaam de nieuwste meeting — en overschrijft de keuze die je twee seconden eerder maakte. De fix was geen slimmere guard; het was de auto-select volledig verwijderen. Elke lijst die dingen namens de gebruiker selecteert, gaat vroeg of laat met de gebruiker vechten.
Het verwijderen legde de tweede race bloot. Auto-navigatie springt naar een meeting op het moment dat zijn sessie eindigt — wat kan zijn vóórdat die sessie klaar is met schrijven naar de lokale SQLite-database. Navigeer te snel en je komt aan bij een meeting die nog niet bestaat. De geshipte fix is een delay van 500 milliseconden voordat sessies worden geladen bij aankomst in de detailweergave, en de navigatiehandler draagt zijn eigen hedges — wachten op did-finish-load van het venster plus 100ms als het dashboard net was aangemaakt, 50ms als het al open stond. Onze lezing: sessie-einde-navigatie kruist drie timingdomeinen — de databaseschrijfactie, de window-load en de React-mount — en elk kreeg zijn eigen kleine delay. Het werkt, en we zeggen er eerlijk bij dat een stapel magic numbers eerlijke schuld is, geen overwinning.
De screenshot die ouder is dan zijn eigen meeting
Nog een aanname sneuvelde in deze release: "screenshots horen bij een sessie dan en slechts dan als ze tijdens die sessie zijn genomen." Volstrekt logisch. Fout. Echte gebruikers drukken Cmd+H op de vacature, de agenda, de code die ze zo gaan bespreken — vóór ze op Start drukken. De Report-tab matchte screenshots strikt op het tijdvenster van de sessie, dus die voorbereidings-screenshots verdwenen uit het rapport waarvoor ze genomen waren. De fix verbreedde het matchvenster met 60 seconden vóór sessiestart. (De tijdvenster-machinerie zelf is ouder — die shipte stilletjes in v1.6.15; de bijdrage van v1.7.3 is haar leren dat meetings iets eerder beginnen dan ze beginnen.)
Vijf fixes in achtentwintig minuten
Het oorlogsverhaal van deze release zit helemaal niet in de tijdlijn — het zit in de Windows-onboarding-overlay, en het is een schoolvoorbeeld van een "fix de fix"-keten: vijf commits tussen 10:50 en 11:18 op dezelfde ochtend.
GeekBye's hoofdvenster gebruikt mouse-passthrough — een hook die Electron's setIgnoreMouseEvents bij elke muisbeweging toggelt zodat klikken door transparante gebieden heen vallen. Tijdens de onboarding op Windows vocht die hook met de tutorial-overlay, en bij de stap waar het dashboardvenster verschijnt, bevroor de app. Fix één: laat de hook niets doen zolang onboarding actief is. Vrede door ontwapening.
Behalve dat de onboardingknoppen nu niet meer reageerden, omdat event forwarding de klikken doorstuurde naar het dashboardvenster onder de overlay. Fixes twee en drie prutsten met forward: false per wizard. Toen kwam de commit die de echte oorzaak vond: wanneer het dashboardvenster opent, reset zijn draghandler het hoofdvenster naar click-through-modus — en de eerste fix had de passthrough-hook passief gemaakt, waardoor niets meer overbleef om die verstoring te corrigeren. De echte fix keerde de strategie om: de hook her-assert nu actief setIgnoreMouseEvents(false) bij elke muisbeweging tijdens onboarding, juist omdat externe code hem elk moment kan resetten. Hij verwijderde ook 75 regels van de eerdere per-wizard-workarounds.
En zelfs toen kwam er een vijfde commit, want de inputoorlog winnen is nog niet de z-orderoorlog winnen: de overlay en het dashboard zaten op hetzelfde always-on-top-niveau, en Windows haalt het venster naar voren dat focus krijgt. De overlay verhuisde naar een hoger vensterniveau en brengt zichzelf met een delay opnieuw naar voren nadat het dashboard verschijnt. De boog is het onthouden waard: een passieve fix die je enige verdediger ontwapent, is erger dan het oorspronkelijke gevecht.
Drie dingen die deze release ons leerde
- Navigatie-upgrades leggen state-bugs bloot. De auto-select-race bestond al vóór v1.7.3; een dropdown liet je hem alleen nooit voelen. Op het moment dat meetings een pagina werden waar je bewust naartoe navigeert, werd elk stuk code dat dingen voor jou selecteerde een bug.
- Tijdgrenzen rond gebruikersintentie hebben speling nodig. Sessies, opnames, rapporten — gebruikers handelen net vóór en net na het officiële venster van de machine. De screenshot-buffer van 60 seconden is één regel die weergeeft hoe mensen zich echt gedragen.
- Maak je corrigerende code nooit passief. De Windows-freeze kostte vijf fixes omdat fix één het enige mechanisme uitschakelde dat externe verstoring kon tegengaan. Als andere code je invariant elk moment kan breken, is het jouw taak hem continu te her-asserten, niet om je terug te trekken.
Voor het vorige hoofdstuk in het v1-verhaal — twee gebrande apps bouwen vanuit deze ene codebase — zie één codebase, twee apps: white-labelen zonder te forken (v1.7.1); en voor de hele boog, de anatomie van software tot in de perfectie uitbrengen.
