Pourquoi l'enregistrement d'écran capture le mauvais moniteur (et notre correctif)

Voici un bug qui n'existe que si vous possédez deux moniteurs — c'est pourquoi il a vécu tranquillement un moment. Vous travaillez sur votre écran latéral, vous lancez un enregistrement GeekBye, et il enregistre votre moniteur principal. Celui avec la barre de menus. Celui que vous ne regardiez pas.

Le même défaut, plus discret et pire, frappait les captures d'écran que GeekBye envoie à l'IA pour le contexte : appuyez sur le raccourci de capture sur votre second moniteur, et l'IA reçoit une image du premier. Aucun signe visuel — l'assistant répond simplement à propos du mauvais écran et vous vous demandez pourquoi il est perdu. GeekBye v2.0.10 a corrigé les deux.

Deux pipelines, une même valeur par défaut paresseuse

La capture d'écran sur le bureau, ce sont deux chemins de code distincts, et tous deux avaient indépendamment choisi l'écran principal :

• L'enregistrement vidéo énumérait les sources d'écran disponibles et prenait la première — sources[0]. Sur macOS, c'est en pratique toujours l'écran principal. Pas de sélecteur, aucune logique sur l'endroit où vous étiez réellement. Le commentaire dans notre propre code disait littéralement "auto-select first screen source."
• Les captures d'écran utilisaient la commande screencapture de macOS avec le flag -m. Ce flag n'a qu'un seul sens : écran principal uniquement. Codé en dur.

Aucun des deux chemins ne posait jamais la question qui compte : sur quel écran est l'utilisateur ?

Une chose qui n'a jamais été cassée, à clarifier parce qu'on suppose le contraire : basculer entre les Spaces de macOS sur le même moniteur a toujours fonctionné. La capture se fait au niveau de l'écran — elle attrape le Space visible sur l'écran choisi. Le bug n'a jamais concerné les Spaces. Il a toujours concerné le choix du mauvais écran physique.

Le correctif qui semblait évident — et qui était faux

Le bon signal paraît simple : capturer l'écran sur lequel l'utilisateur se trouve. Notre première implémentation s'ancrait sur la fenêtre d'overlay de GeekBye — capturer l'écran où vit l'overlay.

La revue de code l'a tué, à juste titre. L'overlay de GeekBye est créé comme une fenêtre à zone de travail complète sur l'écran principal, à la position (0,0). Il ne se déplace vers un autre moniteur que si vous traînez physiquement sa pastille là-bas — et les raccourcis clavier qui le décalent se limitent aux dimensions de l'écran principal, donc ils ne peuvent pas du tout le déplacer vers un second moniteur. Ancrer la capture sur l'overlay signifiait : pour chaque utilisateur qui n'avait pas traîné l'overlay sur son écran de travail, le « correctif » revenait droit sur l'écran principal. Il n'aurait quasiment corrigé personne — tout en ayant l'air, lors d'un test rapide sur une machine de dev à un seul moniteur, de fonctionner.

Le bon ancrage, c'est le curseur. Là où est votre souris, c'est l'écran sur lequel vous travaillez — et c'est correct pour toutes les façons dont une capture démarre : un raccourci clavier se déclenche là où vous pointez, et cliquer sur le bouton Enregistrer place votre curseur sur cet écran par définition. Le correctif final est une fonction de deux lignes : l'écran le plus proche du curseur. La vidéo aligne sa source de capture sur l'id de cet écran ; les captures passent les limites de cet écran à screencapture -R (un rectangle précis) au lieu du flag -m d'écran principal.

Nous avons choisi -R (un rectangle explicite en coordonnées globales d'écran) plutôt que -D (un index d'écran) délibérément : l'index d'écran de l'OS n'a aucune correspondance garantie avec l'ordre des écrans du framework, donc un index serait un second jeu de devinettes. Un rectangle issu des limites réelles de l'écran est sans ambiguïté — et nous avons vérifié le comportement du flag, y compris les coordonnées négatives pour les écrans placés à gauche du principal, sur une vraie configuration multi-écran avant de livrer.

Pourquoi c'est un bon bug pédagogique

1. « Capturer l'écran » cache une décision. Sur un seul écran, il n'y a pas de décision, alors la décision n'est jamais conçue — elle est prise par défaut. Le multi-écran, c'est là où chaque valeur par défaut implicite remonte à la surface.
2. Se tromper en silence est pire que se tromper à la vue de tous. Le bug vidéo agaçait les gens. Le bug des captures trompait l'IA, de façon invisible. Quand vous construisez des fonctionnalités qui nourrissent un modèle en contexte, une entrée fausse produit une sortie fausse avec assurance, sans aucune erreur nulle part. Ce sont les défaillances qu'il faut traquer le plus fort.
3. Un correctif qui passe sur votre machine peut échouer sur celle de tous les autres. La version ancrée sur l'overlay fonctionnait dans un test à un seul moniteur. Tout l'intérêt du bug, ce sont les moniteurs multiples — et le relecteur a raisonné sur la position réelle de la fenêtre plutôt que de se fier au test vert. La revue n'est pas un tampon posé sur du code qui marche ; c'est un second modèle du pourquoi le code marche.

GeekBye v2.0.10 livre le correctif basé sur le curseur pour l'enregistrement comme pour les captures. Si vous utilisez plusieurs écrans, la capture vous suit désormais.

Pour les versions voisines de cette série, voyez pourquoi votre notetaker IA arrête d'enregistrer en pleine réunion (v2.0.9) et pourquoi la transcription IA écorche les termes techniques (v2.0.11). Pour le comportement de l'overlay pendant les appels, voyez comment rester invisible pendant le partage d'écran.