Meetingek, amiket tényleg megtalálsz újra: a timeline kiadás

2026 januárjára a GeekBye felhasználóinak előzményproblémájuk lett. Az app remekül rögzítette és elemezte a meetingjeiket — aztán egy legördülő menübe iktatta őket. Egy legördülő menü három elemhez rendben van. A tizenötödik meeting környékén „az a múlt keddi interjú" már régészeti expedíció volt egyforma kinézetű sorok között. A v1.7.3 — 64 commit december közepe és január 16. között — az a kiadás, amelyben a meetingek olyasmivé váltak, amit tényleg meg lehet találni újra.

(Egy könyvelési megjegyzés, mert a git history akkor is őszinte, amikor a verziószámok nem: nincs v1.7.2 release tag. A verziót megemeltük, de a következő kiadott tag a v1.7.3 volt, így a v1.7.2-korszak Windows-javításai ebben a kiadásban utaztak.)

Legördülő menüből timeline

A címlapos változás egyetlen pull request: 12 fájl, +640 sor, nagy részük egy új, 381 soros MeetingsTimeline komponens. A legördülő menüből görgethető timeline lett meeting-kártyákkal, négy csoportba rendezve — Today, Yesterday, This Week, Older (ma, tegnap, ezen a héten, régebbi) —, a dátumok pedig úgy jelennek meg, ahogy egy ember mondaná: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM az aktuális hétre, és Jan 5, 2:30 PM azon túl. A Cmd/Ctrl+K egy keresőmezőre fókuszál, amely cím szerint szűr. A meeting részletnézete igazi navigációs oldal lett, így a navbar vissza és előre gombjai végre jelentenek valamit, a breadcrumb pedig nem azt írja többé, hogy „Meetings / Meeting", hanem azt, hogy „Meetings / Interview with John" (három ponttal csonkolva, mert mindig lesz valaki, aki regényként nevezi el a meetingjét).

Vele együtt két apró életminőség-javítás is kiment: egy törlésgomb a meetingnézeten belül (amely törlés után visszavisz a timeline-ra, ahelyett hogy egy halott oldalon hagyna), és az automatikus navigáció — amikor egy hallgatási session tényleges átirat-tartalommal ér véget, a dashboard közvetlenül annak a meetingnek a részletoldalán nyílik meg. Leteszed a hívást, látod a meetinget. Az üresen végződő sessionök csendben törlődnek, ahelyett hogy telezsúfolnák a timeline-t.

A versenyhelyzet, amit a navigáció javításával teremtesz

Íme a rész, amit a changelog nem mond el. A régi meetinglistának volt egy szokása: minden betöltéskor automatikusan kijelölte a legújabb sessiont. Ártalmatlan, amíg a lista egy legördülő menü volt, amihez ritkán nyúltál. Végzetes abban a pillanatban, amikor a meetingek navigálható oldallá váltak: rákattintasz az 5-ös meetingre, egy háttérbeli refetch befejeződik, és a lista készségesen kijelöli a legújabb meetinget — felülírva a választást, amit két másodperce hoztál. A javítás nem egy okosabb őrfeltétel volt, hanem az auto-select teljes törlése. Minden lista, amely a felhasználó helyett jelöl ki dolgokat, előbb-utóbb a felhasználó ellen fog harcolni.

Az eltávolítása fedte fel a második versenyhelyzetet. Az automatikus navigáció abban a pillanatban ugrik a meetingre, amikor a sessionje véget ér — ami lehet azelőtt, hogy az a session befejezte volna az írást a helyi SQLite adatbázisba. Navigálj túl gyorsan, és egy még nem létező meetinghez érkezel. A kiadott javítás egy 500 ezredmásodperces késleltetés a sessionök betöltése előtt a részletnézetbe érkezéskor, és a navigációs handler is hordozza a saját biztosítékait — várd meg az ablak did-finish-load eseményét plusz 100ms-ot, ha a dashboard épp most jött létre, 50ms-ot, ha már nyitva volt. A mi olvasatunk: a session végi navigáció három időzítési tartományon lép át — az adatbázis-íráson, az ablakbetöltésen és a React mounton —, és mindegyik megkapta a maga kis késleltetését. Működik, és kimondjuk kereken: egy halom mágikus szám becsületesen bevallott adósság, nem győzelem.

A screenshot, ami megelőzi a saját meetingjét

Még egy feltevés halt meg ebben a kiadásban: „a screenshot akkor és csak akkor tartozik egy sessionhöz, ha az alatt készült." Tökéletesen logikus. Téves. A valódi felhasználók Cmd+H-t nyomnak az álláshirdetésen, a napirenden, a kódon, amiről mindjárt beszélni fognak — mielőtt megnyomnák a Startot. A Report fül szigorúan a session időintervallumához illesztette a screenshotokat, így ezek a felkészülési screenshotok eltűntek pont abból a reportból, amelyhez készültek. A javítás 60 másodperccel szélesítette ki az illesztési ablakot a session kezdete előtt. (Maga az időintervallum-gépezet régebbi — csendben már a v1.6.15-ben kiment; a v1.7.3 hozzájárulása az, hogy megtanította neki: a meetingek kicsivel azelőtt kezdődnek, hogy elkezdődnének.)

Öt javítás huszonnyolc perc alatt

Ennek a kiadásnak a harctéri sztorija egyáltalán nem a timeline-ban van — a Windows onboarding overlayben van, és tankönyvi „javítsd meg a javítást" lánc: öt commit 10:50 és 11:18 között, ugyanazon a délelőttön.

A GeekBye főablaka mouse passthrough-t használ — egy hookot, amely minden egérmozgásnál átkapcsolja az Electron setIgnoreMouseEvents beállítását, hogy a kattintások átessenek az átlátszó területeken. A Windows onboarding alatt ez a hook harcolt a tutorial overlayjel, és annál a lépésnél, ahol a dashboard-ablak megjelenik, az app lefagyott. Első javítás: a hook ne csináljon semmit, amíg az onboarding aktív. Béke lefegyverzés által.

Csakhogy most az onboarding gombjai nem reagáltak, mert az eseménytovábbítás az overlay alatti dashboard-ablaknak szállította ki a kattintásokat. A második és harmadik javítás a forward: false beállítást csavargatta varázslónként. Aztán jött a commit, amely megtalálta a valódi kiváltó okot: amikor a dashboard-ablak megnyílik, az ő drag handlere visszaállítja a főablakot click-through módba — az első javítás pedig passzívvá tette a passthrough hookot, ami azt jelentette, hogy nem maradt semmi, ami korrigálhatta volna a beavatkozást. Az igazi javítás megfordította a stratégiát: a hook mostantól aktívan újraérvényesíti a setIgnoreMouseEvents(false)-t minden egérmozgásnál az onboarding alatt, pontosan azért, mert külső kód bármikor visszaállíthatja. Ráadásul törölt 75 sort a korábbi varázslónkénti kerülőmegoldásokból.

És még ekkor is jött egy ötödik commit, mert az input-háború megnyerése nem a z-order-háború megnyerése: az overlay és a dashboard ugyanazon az always-on-top szinten ült, a Windows pedig azt az ablakot emeli felülre, amelyik fókuszt kap. Az overlay magasabb ablakszintre költözött, és késleltetéssel újra felülre emeli magát, miután a dashboard megjelenik. Az ívet érdemes megjegyezni: egy passzív javítás, amely lefegyverzi az egyetlen védelmeződet, rosszabb, mint az eredeti harc.

Három dolog, amit ez a kiadás tanított nekünk

1. A navigációs fejlesztések állapothibákat hoznak felszínre. Az auto-select versenyhelyzet a v1.7.3 előtt is létezett; egy legördülő menü egyszerűen sosem hagyta, hogy megérezd. Abban a pillanatban, hogy a meetingek tudatosan navigált oldallá váltak, minden kódrészlet, amely helyetted jelölt ki dolgokat, hibává vált.
2. A felhasználói szándék körüli időhatároknak lazaság kell. Sessionök, felvételek, reportok — a felhasználók kicsivel a gép hivatalos ablaka előtt és után cselekszenek. A 60 másodperces screenshot-buffer egyetlen sor, amely azt tükrözi, ahogyan az emberek valójában viselkednek.
3. Soha ne tedd passzívvá a korrekciós kódodat. A Windows-lefagyás öt javítást igényelt, mert az első javítás kikapcsolta az egyetlen mechanizmust, amely ellensúlyozhatta volna a külső beavatkozást. Ha valamilyen másik kód bármikor eltörheti az invariánsodat, a dolgod az, hogy folyamatosan újraérvényesítsd — nem az, hogy leszerelj.

A v1-történet előző fejezetéért — két brandelt app építése ebből az egy kódbázisból — lásd egy kódbázis, két app: hogyan white-label-ezz fork nélkül (v1.7.1); a teljes ívért pedig a szoftver tökéletesre szállításának anatómiája.