Perché la Registrazione dello Schermo Cattura il Monitor Sbagliato (e la Nostra Correzione)

Ecco un bug che esiste solo se possiedi due monitor — ed è per questo che ha vissuto tranquillo per un po'. Lavori sullo schermo laterale, avvii una registrazione di GeekBye, e registra il monitor principale. Quello con la barra dei menu. Quello che non stavi guardando.

Lo stesso difetto, più silenzioso e peggiore, colpiva gli screenshot che GeekBye invia all'IA per il contesto: premi la scorciatoia di cattura sul secondo monitor e l'IA riceve un'immagine del primo. Non c'è alcun segnale visivo — l'assistente risponde semplicemente sullo schermo sbagliato e tu ti chiedi perché sia confuso. GeekBye v2.0.10 ha corretto entrambi.

Due pipeline, uno stesso valore predefinito pigro

La cattura dello schermo sul desktop sono due percorsi di codice separati, ed entrambi avevano scelto in autonomia lo schermo principale:

• La registrazione video enumerava le sorgenti di schermo disponibili e prendeva la prima — sources[0]. Su macOS quella è, di fatto, sempre lo schermo principale. Nessun selettore, nessuna logica su dove ti trovassi davvero. Il commento nel nostro stesso codice diceva letteralmente "auto-select first screen source."
• Gli screenshot usavano il comando screencapture di macOS con il flag -m. Quel flag ha esattamente un significato: solo schermo principale. Fisso nel codice.

Nessuno dei due percorsi poneva mai la domanda che conta: su quale schermo si trova l'utente?

Una cosa che non è mai stata rotta, e vale la pena chiarirla perché si dà per scontato il contrario: passare tra gli Spaces di macOS sullo stesso monitor ha sempre funzionato. La cattura avviene a livello di schermo — afferra lo Space visibile sullo schermo scelto. Il bug non ha mai riguardato gli Spaces. Ha sempre riguardato la scelta dello schermo fisico sbagliato.

La correzione che sembrava ovvia — ed era sbagliata

Il segnale corretto sembra facile: catturare lo schermo su cui si trova l'utente. La nostra prima implementazione si ancorava alla finestra dell'overlay di GeekBye — catturare lo schermo su cui vive l'overlay.

La code review l'ha uccisa, giustamente. L'overlay di GeekBye viene creato come finestra a piena area di lavoro sullo schermo principale, in posizione (0,0). Si sposta su un altro monitor solo se ne trascini fisicamente la pillola lì — e le scorciatoie da tastiera che lo spostano si limitano alle dimensioni dello schermo principale, quindi non possono affatto spostarlo su un secondo monitor. Ancorare la cattura all'overlay significava: per ogni utente che non avesse per caso trascinato l'overlay sul proprio schermo di lavoro, la "correzione" tornava dritta allo schermo principale. Non avrebbe corretto quasi nessuno — pur sembrando, in un test rapido su una macchina di sviluppo a monitor singolo, che funzionasse.

L'ancora giusta è il cursore. Dovunque sia il mouse, quello è lo schermo su cui stai lavorando — ed è corretto per ogni modo in cui parte una cattura: una scorciatoia da tastiera scatta dove stai puntando, e cliccare il pulsante Registra mette il cursore su quello schermo per definizione. La correzione finale è una funzione di due righe: lo schermo più vicino al cursore. Il video allinea la sua sorgente di cattura all'id di quello schermo; gli screenshot passano i limiti di quello schermo a screencapture -R (un rettangolo specifico) invece del flag -m di schermo principale.

Abbiamo scelto -R (un rettangolo esplicito in coordinate globali di schermo) invece di -D (un indice di schermo) di proposito: l'indice di schermo del sistema operativo non ha corrispondenza garantita con l'ordinamento degli schermi del framework, quindi un indice sarebbe un secondo gioco a indovinare. Un rettangolo ricavato dai limiti reali dello schermo è inequivocabile — e abbiamo verificato il comportamento del flag, incluse le coordinate negative per schermi posizionati a sinistra del principale, su una vera postazione multi-monitor prima di rilasciare.

Perché questo è un buon bug didattico

1. "Cattura lo schermo" nasconde una decisione. Su un singolo schermo non c'è decisione, quindi la decisione non viene mai progettata — viene presa di default. Il multi-monitor è dove ogni valore predefinito implicito viene a galla.
2. Sbagliare in silenzio è peggio che sbagliare in bella vista. Il bug del video infastidiva le persone. Il bug degli screenshot ingannava l'IA, in modo invisibile. Quando costruisci funzionalità che alimentano un modello con del contesto, un input sbagliato produce un output sicuro di sé e sbagliato, senza alcun errore da nessuna parte. Sono queste le falle che vale di più la pena stanare.
3. Una correzione che passa sulla tua macchina può fallire su quella di tutti gli altri. La versione ancorata all'overlay funzionava in un test a monitor singolo. Tutto il senso del bug sono i monitor multipli — e il revisore ha ragionato sulla posizione reale della finestra invece di fidarsi del test verde. La review non è un timbro su del codice che funziona; è un secondo modello del perché il codice funziona.

GeekBye v2.0.10 rilascia la correzione basata sul cursore sia per la registrazione sia per gli screenshot. Se usi più schermi, la cattura ora ti segue.

Per le release vicine di questa serie, vedi perché il tuo notetaker AI smette di registrare a metà riunione (v2.0.9) e perché la trascrizione AI fraintende i termini tecnici (v2.0.11). Su come si comporta l'overlay durante le chiamate, vedi come restare invisibile durante la condivisione dello schermo.