Riunioni che finalmente ritrovi: la release della timeline

A gennaio 2026 gli utenti di GeekBye avevano un problema di cronologia. L'app registrava e analizzava le loro riunioni benissimo — e poi le archiviava in un dropdown. Un dropdown va bene per tre elementi. Alla quindicesima riunione, "quel colloquio di martedì scorso" era una spedizione archeologica tra righe tutte uguali. v1.7.3 — 64 commit tra metà dicembre e il 16 gennaio — è la release in cui le riunioni sono diventate qualcosa che finalmente ritrovi.

(Una nota di contabilità, perché la cronologia git è onesta anche quando i numeri di versione non lo sono: non esiste un tag di release v1.7.2. La versione era stata incrementata, ma il tag successivo a uscire fu v1.7.3, quindi i fix per Windows dell'era v1.7.2 sono saliti a bordo di questa release.)

Dal dropdown alla timeline

Il cambiamento da titolo è una sola pull request: 12 file, +640 righe, in gran parte un nuovo componente MeetingsTimeline da 381 righe. Il dropdown è diventato una timeline scorrevole di card di riunione, raggruppate in quattro bucket — Today, Yesterday, This Week, Older (oggi, ieri, questa settimana, più vecchie) — con date scritte come le direbbe una persona: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM per questa settimana e Jan 5, 2:30 PM oltre. Cmd/Ctrl+K porta il focus su una casella di ricerca che filtra per titolo. La vista di dettaglio della riunione è diventata una vera pagina di navigazione, così i pulsanti indietro e avanti della navbar finalmente significano qualcosa, e il breadcrumb ha smesso di dire "Meetings / Meeting" e ha iniziato a dire "Meetings / Interview with John" (troncato con puntini di sospensione, perché ci sarà sempre qualcuno che intitola una riunione come un romanzo).

Con la release sono arrivate due piccole comodità: un pulsante di eliminazione dentro la vista della riunione (che dopo l'eliminazione ti riporta alla timeline, invece di abbandonarti su una pagina morta), e la navigazione automatica — quando una sessione di ascolto finisce con del contenuto di trascrizione reale, la dashboard si apre direttamente sulla pagina di dettaglio di quella riunione. Chiudi la chiamata, vedi la riunione. Le sessioni che finiscono vuote vengono eliminate in silenzio invece di ingombrare la timeline.

La race che crei migliorando la navigazione

Ecco la parte che il changelog non racconta. La vecchia lista delle riunioni aveva un'abitudine: a ogni caricamento auto-selezionava la sessione più recente. Innocuo quando la lista era un dropdown che toccavi di rado. Fatale nel momento in cui le riunioni sono diventate una pagina in cui navighi: clicchi la riunione n. 5, un refetch in background si completa, e la lista, premurosa, seleziona la riunione più recente — sovrascrivendo la scelta che avevi fatto due secondi prima. Il fix non è stato un guard più furbo; è stato cancellare del tutto l'auto-selezione. Qualsiasi lista che seleziona cose per conto dell'utente prima o poi combatterà contro l'utente.

Rimuoverla ha esposto la seconda race. La navigazione automatica salta a una riunione nell'istante in cui la sua sessione finisce — che può essere prima che quella sessione abbia finito di scrivere sul database SQLite locale. Naviga troppo in fretta e arrivi a una riunione che non esiste ancora. Il fix spedito è un ritardo di 500 millisecondi prima di caricare le sessioni quando si arriva alla vista di dettaglio, e il gestore di navigazione porta le sue coperture — aspettare il did-finish-load della finestra più 100ms se la dashboard era appena stata creata, 50ms se era già aperta. La nostra lettura: la navigazione a fine sessione attraversa tre domini temporali — la scrittura su database, il caricamento della finestra e il mount di React — e ognuno ha ricevuto il suo piccolo ritardo. Funziona, e lo diciamo chiaramente: una pila di numeri magici è debito onesto, non una vittoria.

Lo screenshot che precede la sua stessa riunione

Un'altra assunzione è morta in questa release: "gli screenshot appartengono a una sessione se e solo se sono stati scattati durante di essa". Perfettamente logica. Sbagliata. Gli utenti veri premono Cmd+H sull'annuncio di lavoro, sull'agenda, sul codice di cui stanno per discutere — prima di premere Start. La tab Report abbinava gli screenshot all'intervallo temporale della sessione in modo rigido, quindi quegli screenshot di preparazione sparivano dal report per cui erano stati fatti. Il fix ha allargato la finestra di abbinamento di 60 secondi prima dell'inizio della sessione. (La macchina degli intervalli temporali in sé è più vecchia — era uscita in sordina nella v1.6.15; il contributo della v1.7.3 è insegnarle che le riunioni iniziano un po' prima di iniziare.)

Cinque fix in ventotto minuti

La storia di guerra di questa release non sta affatto nella timeline — sta nell'overlay di onboarding di Windows, ed è una catena da manuale di "fixare il fix": cinque commit tra le 10:50 e le 11:18 della stessa mattina.

La finestra principale di GeekBye usa il passthrough del mouse — un hook che commuta il setIgnoreMouseEvents di Electron a ogni movimento del mouse perché i clic cadano attraverso le aree trasparenti. Durante l'onboarding su Windows quell'hook litigava con l'overlay del tutorial, e al passo in cui compare la finestra della dashboard l'app si bloccava. Fix uno: far sì che l'hook non faccia nulla mentre l'onboarding è attivo. La pace tramite il disarmo.

Se non che ora i pulsanti dell'onboarding non rispondevano, perché l'inoltro degli eventi spediva i clic alla finestra della dashboard sotto l'overlay. I fix due e tre hanno trafficato con forward: false wizard per wizard. Poi è arrivato il commit che ha trovato la vera causa radice: quando la finestra della dashboard si apre, il suo gestore di drag riporta la finestra principale in modalità click-through — e il primo fix aveva reso passivo l'hook di passthrough, il che significava che non era rimasto nulla a correggere l'interferenza. Il fix vero ha invertito la strategia: l'hook adesso riafferma attivamente setIgnoreMouseEvents(false) a ogni movimento del mouse durante l'onboarding, proprio perché del codice esterno può resettarlo in qualsiasi momento. Ha anche cancellato 75 righe dei precedenti workaround per singolo wizard.

E anche allora c'è stato un quinto commit, perché vincere la guerra dell'input non è vincere la guerra dello z-order: l'overlay e la dashboard sedevano allo stesso livello always-on-top, e Windows porta in primo piano la finestra che riceve il focus. L'overlay è passato a un livello di finestra più alto e si rialza da solo con un ritardo dopo che la dashboard compare. L'arco merita di essere ricordato: un fix passivo che disarma il tuo unico difensore è peggio della lite originale.

Tre cose che questa release ci ha insegnato

1. Gli upgrade di navigazione fanno emergere i bug di stato. La race dell'auto-selezione esisteva già prima della v1.7.3; un dropdown semplicemente non te la faceva mai sentire. Nel momento in cui le riunioni sono diventate una pagina in cui navighi deliberatamente, ogni pezzo di codice che selezionava cose per te è diventato un bug.
2. I confini temporali attorno all'intenzione dell'utente hanno bisogno di gioco. Sessioni, registrazioni, report — gli utenti agiscono un po' prima e un po' dopo la finestra ufficiale della macchina. Il buffer di 60 secondi per gli screenshot è una riga che riflette come si comportano davvero le persone.
3. Non rendere mai passivo il tuo codice correttivo. Il freeze di Windows ha richiesto cinque fix perché il fix uno ha spento l'unico meccanismo che poteva contrastare l'interferenza esterna. Se un altro codice può rompere la tua invariante in qualsiasi momento, il tuo lavoro è riaffermarla di continuo, non ritirarti.

Per il capitolo precedente della storia v1 — costruire due app brandizzate da questa unica codebase — vedi una codebase, due app: come fare white-label senza fork (v1.7.1); e per tutto l'arco, l'anatomia del pubblicare software fino alla perfezione.