Derfor optager skærmoptagelsen den forkerte skærm (og vores fix)

Her er en bug, der kun findes, hvis du har to skærme — og derfor levede den stille et stykke tid. Du arbejder på din sideskærm, starter en GeekBye-optagelse, og den optager din primære skærm. Den med menulinjen. Den, du ikke kiggede på.

Samme defekt, mere stille og værre, ramte de skærmbilleder, GeekBye sender til AI'en som kontekst: tryk på skærmbillede-genvejen på din anden skærm, og AI'en får et billede af din første. Der er intet visuelt tegn — assistenten svarer bare om den forkerte skærm, og du sidder tilbage og undrer dig over, hvorfor den er forvirret. GeekBye v2.0.10 fiksede begge.

To pipelines, én doven standard

Skærmoptagelse på skrivebordet er to separate kodeveje, og begge havde uafhængigt af hinanden valgt den primære skærm:

• Videooptagelse opremsede de tilgængelige skærmkilder og tog den første — sources[0]. På macOS er det reelt altid hovedskærmen. Ingen vælger, ingen logik om, hvor du faktisk var. Kommentaren i vores egen kode sagde bogstaveligt talt "auto-select first screen source."
• Skærmbilleder brugte macOS-kommandoen screencapture med flaget -m. Det flag har præcis én betydning: kun hovedskærmen. Hårdkodet.

Ingen af vejene stillede nogensinde det spørgsmål, der betyder noget: hvilken skærm er brugeren på?

Én ting, der aldrig var i stykker, værd at få på plads, fordi folk antager, at den var det: at skifte mellem macOS Spaces på samme skærm virkede altid. Optagelsen sker på skærmniveau — den tager det Space, der er synligt på den valgte skærm. Buggen handlede aldrig om Spaces. Den handlede altid om at vælge den forkerte fysiske skærm.

Fixet, der så oplagt ud — og var forkert

Det rigtige signal virker nemt: fang den skærm, brugeren er på. Vores første implementering forankrede sig i GeekByes overlay-vindue — fang den skærm, overlayet lever på.

Kodegennemgangen dræbte det, med rette. GeekByes overlay oprettes som et vindue over hele arbejdsområdet på den primære skærm, i position (0,0). Det flytter kun til en anden skærm, hvis du fysisk trækker dets pille derhen — og genvejene, der skubber det rundt, låser til den primære skærms mål, så de kan slet ikke flytte det til en anden skærm. At forankre optagelsen i overlayet betød: for hver bruger, der ikke tilfældigvis trak overlayet over på deres arbejdsskærm, opløste "fixet" sig lige tilbage til den primære skærm. Det ville næsten ikke have fikset noget for nogen — mens det, i en hurtig test på en udviklingsmaskine med én skærm, så ud til at virke.

Det rigtige anker er markøren. Hvor end din mus er, er det den skærm, du arbejder på — og det er rigtigt for enhver måde en optagelse starter på: en genvej udløses der, hvor du peger, og at klikke på Record-knappen placerer din markør på den skærm per definition. Det endelige fix er en tolinjers funktion: skærmen nærmest markøren. Video matcher sin optagelseskilde til den skærms id; skærmbilleder sender den skærms grænser til screencapture -R (et bestemt rektangel) i stedet for -m-hovedskærmsflaget.

Vi valgte -R (et eksplicit rektangel i globale skærmkoordinater) frem for -D (et skærmindeks) bevidst: OS'ets skærmindeks har ingen garanteret sammenhæng med frameworkets skærmrækkefølge, så et indeks ville være endnu et gættespil. Et rektangel fra de faktiske skærmgrænser er utvetydigt — og vi verificerede flagets adfærd, inklusive negative koordinater for skærme placeret til venstre for den primære, på et rigtigt opsæt med flere skærme før udsendelse.

Hvorfor denne er en god lærebug

1. "Fang skærmen" skjuler en beslutning. På én skærm er der ingen beslutning, så beslutningen bliver aldrig designet — den bliver til en standard. Flere skærme er der, hvor hver implicit standard kommer til overfladen.
2. Lydløst-forkert er værre end synligt-forkert. Videobuggen irriterede folk. Skærmbillede-buggen vildledte AI'en, usynligt. Når du bygger funktioner, der fodrer kontekst til en model, producerer et forkert input et selvsikkert forkert output uden nogen fejl nogen steder. Det er de fejl, der er værd at jage hårdest.
3. Et fix, der går igennem på din maskine, kan fejle på alle andres. Den overlay-forankrede version virkede i en test med én skærm. Hele pointen med buggen er flere skærme — og gennemgangen ræsonnerede om vinduets reelle position i stedet for at stole på den grønne test. Gennemgang er ikke et gummistempel på fungerende kode; det er en anden model af, hvorfor koden virker.

GeekBye v2.0.10 leverer det markørbaserede fix til både optagelse og skærmbilleder. Kører du flere skærme, følger optagelsen nu med dig.

For de nærliggende releases i denne serie, se derfor stopper din AI-notetager med at optage midt i mødet (v2.0.9) og derfor hører AI-transskription tekniske termer forkert (v2.0.11). For hvordan overlayet opfører sig under opkald, se hvordan du forbliver usynlig under skærmdeling.