Ședințe pe care chiar le poți regăsi: lansarea cu timeline

Prin ianuarie 2026, utilizatorii GeekBye aveau o problemă cu istoricul. Aplicația le înregistra și le analiza ședințele fără cusur — și apoi le arhiva într-un dropdown. Un dropdown e în regulă pentru trei elemente. Pe la ședința cu numărul cincisprezece, „interviul acela de marțea trecută" devenise o expediție arheologică printre rânduri identice. v1.7.3 — 64 de commit-uri între mijlocul lui decembrie și 16 ianuarie — este lansarea în care ședințele au devenit ceva ce chiar poți regăsi.

(O notă de contabilitate, pentru că istoricul git e onest chiar și când numerele de versiune nu sunt: nu există un tag de release v1.7.2. Versiunea a fost incrementată, dar următorul tag livrat a fost v1.7.3, așa că fix-urile de Windows din era v1.7.2 au călătorit în această lansare.)

De la dropdown la timeline

Schimbarea-vedetă e un singur pull request: 12 fișiere, +640 de linii, majoritatea o componentă nouă MeetingsTimeline de 381 de linii. Dropdown-ul a devenit un timeline derulabil de carduri de ședință, grupate în patru găleți — Today, Yesterday, This Week, Older (azi, ieri, săptămâna aceasta, mai vechi) — cu datele redate așa cum le-ar spune un om: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM pentru săptămâna curentă și Jan 5, 2:30 PM dincolo de ea. Cmd/Ctrl+K focalizează o căsuță de căutare care filtrează după titlu. Vizualizarea de detaliu a ședinței a devenit o pagină de navigare adevărată, așa că butoanele înapoi și înainte din navbar înseamnă în sfârșit ceva, iar breadcrumb-ul a încetat să afișeze „Meetings / Meeting" și a început să afișeze „Meetings / Interview with John" (trunchiat cu puncte de suspensie, pentru că mereu va exista cineva care își botează ședința ca pe un roman).

Odată cu el au venit două mici îmbunătățiri de calitate a vieții: un buton de ștergere în interiorul vizualizării ședinței (care te duce înapoi în timeline după ștergere, în loc să te abandoneze pe o pagină moartă) și auto-navigarea — când o sesiune de ascultare se încheie cu transcript real în ea, dashboard-ul se deschide direct pe pagina de detaliu a acelei ședințe. Închizi apelul, vezi ședința. Sesiunile care se termină goale sunt șterse discret, în loc să aglomereze timeline-ul.

Cursa pe care o creezi îmbunătățind navigarea

Iată partea pe care changelog-ul nu ți-o spune. Vechea listă de ședințe avea un obicei: la fiecare încărcare, auto-selecta cea mai nouă sesiune. Inofensiv cât timp lista era un dropdown pe care rar îl atingeai. Fatal în clipa în care ședințele au devenit o pagină prin care navighezi: dai click pe ședința #5, un refetch de fundal se încheie, iar lista selectează serviabil cea mai nouă ședință — suprascriind alegerea pe care ai făcut-o acum două secunde. Reparația nu a fost un guard mai deștept; a fost ștergerea completă a auto-selectării. Orice listă care selectează lucruri în numele utilizatorului va ajunge, mai devreme sau mai târziu, să se lupte cu utilizatorul.

Eliminarea ei a expus a doua cursă. Auto-navigarea sare la o ședință în clipa în care sesiunea ei se termină — ceea ce poate fi înainte ca acea sesiune să fi terminat de scris în baza de date SQLite locală. Navighează prea repede și ajungi la o ședință care încă nu există. Fix-ul livrat este o întârziere de 500 de milisecunde înainte de încărcarea sesiunilor la sosirea în vizualizarea de detaliu, iar handler-ul de navigare își poartă propriile plase de siguranță — așteaptă did-finish-load al ferestrei plus 100ms dacă dashboard-ul tocmai a fost creat, 50ms dacă era deja deschis. Lectura noastră: navigarea la finalul sesiunii traversează trei domenii de timing — scrierea în baza de date, încărcarea ferestrei și mount-ul React — și fiecare a primit propria mică întârziere. Funcționează, și o spunem pe șleau: un teanc de numere magice este datorie asumată onest, nu o victorie.

Screenshot-ul care își precedă propria ședință

Încă o presupunere a murit în această lansare: „screenshot-urile aparțin unei sesiuni dacă și numai dacă au fost făcute în timpul ei." Perfect logic. Greșit. Utilizatorii reali apasă Cmd+H pe anunțul de job, pe agendă, pe codul pe care urmează să-l discute — înainte să apese Start. Tab-ul Report potrivea screenshot-urile cu intervalul de timp al sesiunii în mod strict, așa că acele screenshot-uri de pregătire dispăreau exact din raportul pentru care fuseseră făcute. Fix-ul a lărgit fereastra de potrivire cu 60 de secunde înainte de startul sesiunii. (Mașinăria de intervale de timp în sine e mai veche — a fost livrată discret în v1.6.15; contribuția lui v1.7.3 este că a învățat-o că ședințele încep puțin înainte să înceapă.)

Cinci fix-uri în douăzeci și opt de minute

Povestea de război a acestei lansări nu e deloc în timeline — e în overlay-ul de onboarding de pe Windows, și e un lanț-manual de „repară reparația": cinci commit-uri între 10:50 și 11:18, în aceeași dimineață.

Fereastra principală a GeekBye folosește mouse passthrough — un hook care comută setIgnoreMouseEvents al lui Electron la fiecare mișcare de mouse, astfel încât click-urile să cadă prin zonele transparente. În timpul onboarding-ului pe Windows, hook-ul acela se lupta cu overlay-ul de tutorial, iar la pasul în care apare fereastra de dashboard, aplicația îngheța. Fix-ul unu: fă hook-ul să nu facă nimic cât timp onboarding-ul e activ. Pace prin dezarmare.

Doar că acum butoanele de onboarding nu mai răspundeau, pentru că redirecționarea de evenimente expedia click-urile către fereastra de dashboard aflată sub overlay. Fix-urile doi și trei au meșterit la forward: false per wizard. Apoi a venit commit-ul care a găsit adevărata cauză-rădăcină: când se deschide fereastra de dashboard, handler-ul ei de drag resetează fereastra principală în modul click-through — iar primul fix făcuse hook-ul de passthrough pasiv, ceea ce însemna că nu mai rămăsese nimic care să corecteze interferența. Adevăratul fix a inversat strategia: hook-ul reafirmă acum activ setIgnoreMouseEvents(false) la fiecare mișcare de mouse în timpul onboarding-ului, tocmai pentru că un cod extern îl poate reseta oricând. A șters, în plus, 75 de linii din workaround-urile anterioare per wizard.

Și chiar și atunci a mai fost un al cincilea commit, pentru că a câștiga războiul input-ului nu înseamnă a câștiga războiul de z-order: overlay-ul și dashboard-ul stăteau amândouă pe același nivel always-on-top, iar Windows ridică deasupra oricare fereastră primește focus. Overlay-ul s-a mutat pe un nivel de fereastră mai înalt și se re-ridică singur, cu o întârziere, după ce apare dashboard-ul. Arcul merită reținut: un fix pasiv care îți dezarmează singurul apărător e mai rău decât lupta inițială.

Trei lucruri pe care ni le-a predat această lansare

1. Upgrade-urile de navigare scot la suprafață bug-uri de stare. Cursa de auto-selectare exista dinainte de v1.7.3; un dropdown pur și simplu nu te lăsa niciodată s-o simți. În clipa în care ședințele au devenit o pagină prin care navighezi deliberat, fiecare bucată de cod care selecta lucruri pentru tine a devenit un bug.
2. Granițele de timp din jurul intenției utilizatorului au nevoie de joc. Sesiuni, înregistrări, rapoarte — utilizatorii acționează puțin înainte și puțin după fereastra oficială a mașinii. Buffer-ul de 60 de secunde pentru screenshot-uri e o singură linie care reflectă cum se poartă oamenii de fapt.
3. Nu-ți face niciodată pasiv codul corectiv. Înghețul de pe Windows a cerut cinci fix-uri pentru că fix-ul unu a oprit singurul mecanism care putea contracara interferența externă. Dacă un alt cod îți poate strica invarianta oricând, treaba ta e să o reafirmi continuu, nu să te retragi din post.

Pentru capitolul anterior al poveștii v1 — construirea a două aplicații branded din această unică bază de cod — vezi o singură bază de cod, două aplicații: cum faci white-label fără fork (v1.7.1); iar pentru întregul arc, anatomia livrării de software până la perfecțiune.