
Des réunions qu'on retrouve enfin : la release de la timeline
GeekBye v1.7.3 a remplacé le menu déroulant des réunions par une vraie timeline — dates humaines, recherche, un fil d'Ariane qui dit dans quelle réunion vous êtes. En dessous : une course d'auto-sélection, une capture d'écran antérieure à sa propre réunion, et cinq correctifs Windows en vingt-huit minutes.
En janvier 2026, les utilisateurs de GeekBye avaient un problème d'historique. L'app enregistrait et analysait leurs réunions très bien — puis les classait dans un menu déroulant. Un menu déroulant, ça va pour trois éléments. À la quinzième réunion, « cet entretien de mardi dernier » devenait une expédition archéologique à travers des lignes toutes identiques. v1.7.3 — 64 commits entre mi-décembre et le 16 janvier — est la release où les réunions sont devenues quelque chose qu'on retrouve enfin.
(Une note de comptabilité, parce que l'historique git est honnête même quand les numéros de version ne le sont pas : il n'existe pas de tag de release v1.7.2. La version a été incrémentée, mais le tag suivant à sortir fut v1.7.3, si bien que les correctifs Windows de l'ère v1.7.2 ont voyagé dans cette release.)
Du menu déroulant à la timeline
Le changement vedette tient dans une seule pull request : 12 fichiers, +640 lignes, dont l'essentiel est un nouveau composant MeetingsTimeline de 381 lignes. Le menu déroulant est devenu une timeline défilante de cartes de réunion, regroupées en quatre buckets — Today, Yesterday, This Week, Older (aujourd'hui, hier, cette semaine, plus ancien) — avec des dates rendues comme un humain les dirait : Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM pour cette semaine, et Jan 5, 2:30 PM au-delà. Cmd/Ctrl+K met le focus sur un champ de recherche qui filtre par titre. La vue de détail d'une réunion est devenue une vraie page de navigation, si bien que les boutons précédent et suivant de la barre de navigation veulent enfin dire quelque chose, et le fil d'Ariane a cessé d'afficher « Meetings / Meeting » pour afficher « Meetings / Interview with John » (tronqué par une ellipse, parce qu'il y aura toujours quelqu'un pour nommer une réunion comme un roman).
Deux petites améliorations de confort sont arrivées avec : un bouton de suppression dans la vue de réunion (qui vous ramène à la timeline après suppression, au lieu de vous abandonner sur une page morte), et la navigation automatique — quand une session d'écoute se termine avec du vrai contenu de transcription, le dashboard s'ouvre directement sur la page de détail de cette réunion. Vous raccrochez, vous voyez la réunion. Les sessions qui se terminent vides sont discrètement supprimées au lieu d'encombrer la timeline.
La course qu'on crée en améliorant la navigation
Voici la partie que le changelog ne raconte pas. L'ancienne liste de réunions avait une habitude : à chaque chargement, elle auto-sélectionnait la session la plus récente. Inoffensif quand la liste était un menu déroulant qu'on touchait à peine. Fatal dès que les réunions sont devenues une page où l'on navigue : vous cliquez sur la réunion n° 5, un refetch en arrière-plan se termine, et la liste, serviable, sélectionne la réunion la plus récente — écrasant le choix que vous venez de faire il y a deux secondes. Le correctif n'était pas un garde-fou plus malin ; c'était de supprimer l'auto-sélection tout court. Toute liste qui sélectionne des choses à la place de l'utilisateur finira par se battre contre l'utilisateur.
La retirer a exposé la deuxième course. La navigation automatique saute vers une réunion à l'instant où sa session se termine — ce qui peut être avant que cette session ait fini d'écrire dans la base SQLite locale. Naviguez trop vite et vous arrivez sur une réunion qui n'existe pas encore. Le correctif livré est un délai de 500 millisecondes avant de charger les sessions en arrivant en vue de détail, et le gestionnaire de navigation porte ses propres précautions — attendre le did-finish-load de la fenêtre plus 100ms si le dashboard vient d'être créé, 50ms s'il était déjà ouvert. Notre lecture : la navigation de fin de session traverse trois domaines temporels — l'écriture en base, le chargement de la fenêtre et le montage React — et chacun a reçu son petit délai. Ça marche, et disons-le franchement : une pile de nombres magiques, c'est de la dette honnête, pas une victoire.
La capture d'écran antérieure à sa propre réunion
Une hypothèse de plus est morte dans cette release : « les captures appartiennent à une session si et seulement si elles ont été prises pendant ». Parfaitement logique. Faux. Les vrais utilisateurs font Cmd+H sur l'offre d'emploi, l'agenda, le code dont ils vont discuter — avant d'appuyer sur Start. L'onglet Report faisait correspondre les captures à la plage horaire de la session de façon stricte, donc ces captures de préparation disparaissaient du rapport pour lequel elles avaient été prises. Le correctif a élargi la fenêtre de correspondance de 60 secondes avant le début de session. (La machinerie des plages horaires elle-même est plus ancienne — elle est sortie discrètement en v1.6.15 ; la contribution de v1.7.3 est de lui apprendre que les réunions commencent légèrement avant de commencer.)
Cinq correctifs en vingt-huit minutes
L'anecdote de guerre de cette release n'est pas du tout dans la timeline — elle est dans l'overlay d'onboarding Windows, et c'est une chaîne d'école du « corriger le correctif » : cinq commits entre 10:50 et 11:18 le même matin.
La fenêtre principale de GeekBye utilise le passthrough souris — un hook qui bascule le setIgnoreMouseEvents d'Electron à chaque mouvement de souris pour que les clics traversent les zones transparentes. Pendant l'onboarding sous Windows, ce hook se battait avec l'overlay du tutoriel, et à l'étape où la fenêtre du dashboard apparaît, l'app gelait. Correctif un : faire que le hook ne fasse rien tant que l'onboarding est actif. La paix par le désarmement.
Sauf que maintenant les boutons de l'onboarding ne répondaient plus, parce que le transfert d'événements expédiait les clics vers la fenêtre du dashboard sous l'overlay. Les correctifs deux et trois ont bricolé forward: false assistant par assistant. Puis est arrivé le commit qui a trouvé la vraie cause racine : quand la fenêtre du dashboard s'ouvre, son gestionnaire de drag remet la fenêtre principale en mode click-through — et le premier correctif avait rendu le hook de passthrough passif, ce qui voulait dire qu'il ne restait plus rien pour corriger l'interférence. Le vrai correctif a inversé la stratégie : le hook réaffirme désormais activement setIgnoreMouseEvents(false) à chaque mouvement de souris pendant l'onboarding, précisément parce que du code externe peut le réinitialiser à tout moment. Il a aussi supprimé 75 lignes des contournements précédents par assistant.
Et même là, il y a eu un cinquième commit, parce que gagner la guerre de l'input n'est pas gagner la guerre du z-order : l'overlay et le dashboard siégeaient au même niveau always-on-top, et Windows fait remonter la fenêtre qui reçoit le focus. L'overlay est passé à un niveau de fenêtre supérieur et se re-hisse avec un délai après l'apparition du dashboard. L'arc mérite d'être retenu : un correctif passif qui désarme votre seul défenseur est pire que le combat d'origine.
Trois choses que cette release nous a apprises
- Les améliorations de navigation font remonter les bugs d'état. La course d'auto-sélection existait avant v1.7.3 ; un menu déroulant ne vous laissait simplement jamais la sentir. Dès que les réunions sont devenues une page où l'on navigue délibérément, chaque bout de code qui sélectionnait des choses pour vous est devenu un bug.
- Les frontières temporelles autour de l'intention utilisateur ont besoin de mou. Sessions, enregistrements, rapports — les utilisateurs agissent un peu avant et un peu après la fenêtre officielle de la machine. Le tampon de 60 secondes pour les captures est une ligne qui reflète comment les gens se comportent vraiment.
- Ne rendez jamais votre code correctif passif. Le gel Windows a pris cinq correctifs parce que le correctif un a éteint le seul mécanisme capable de contrer l'interférence externe. Si un autre code peut casser votre invariant à tout moment, votre travail est de le réaffirmer en continu, pas de vous retirer.
Pour le chapitre précédent de l'histoire v1 — construire deux apps de marque depuis cette même base de code — voir une base de code, deux apps : le white-label sans forker (v1.7.1) ; et pour tout l'arc, l'anatomie de livrer un logiciel jusqu'à la perfection.