
Dlaczego nagrywanie ekranu przechwytuje niewłaściwy monitor (i jak to naprawiliśmy)
Na zestawie z dwoma monitorami GeekBye nagrywał i zrzucał obraz z ekranu głównego bez względu na to, na którym ekranie pracowałeś. Poprawka była jedną małą funkcją — ale jej pierwsza wersja była błędna, a code review wychwyciło dlaczego.
Oto błąd, który istnieje tylko wtedy, gdy masz dwa monitory — dlatego przez jakiś czas żył cicho. Pracujesz na bocznym ekranie, uruchamiasz nagrywanie GeekBye, a ono nagrywa Twój monitor główny. Ten z paskiem menu. Ten, na który nie patrzyłeś.
Ta sama wada, cichsza i gorsza, dotknęła zrzuty ekranu, które GeekBye wysyła do AI jako kontekst: naciskasz skrót zrzutu na drugim monitorze, a AI dostaje obraz pierwszego. Nie ma żadnego wizualnego sygnału — asystent po prostu odpowiada na temat złego ekranu, a Ty zastanawiasz się, dlaczego jest zdezorientowany. GeekBye v2.0.10 naprawiło oba.
Dwa mechanizmy, jeden leniwy domyślny wybór
Przechwytywanie ekranu na pulpicie to dwie osobne ścieżki kodu i obie niezależnie wybrały ekran główny:
- Nagrywanie wideo wyliczało dostępne źródła ekranu i brało pierwsze —
sources[0]. Na macOS to praktycznie zawsze ekran główny. Bez selektora, bez żadnej logiki dotyczącej tego, gdzie faktycznie byłeś. Komentarz w naszym własnym kodzie mówił dosłownie "auto-select first screen source" (automatyczny wybór pierwszego źródła ekranu). - Zrzuty ekranu używały macOS-owej komendy
screencapturez flagą-m. Ta flaga ma dokładnie jedno znaczenie: tylko ekran główny. Zaszyte na sztywno.
Żadna ze ścieżek nigdy nie zadała pytania, które ma znaczenie: na którym ekranie jest użytkownik?
Jedna rzecz, która nigdy nie była zepsuta, a warto ją wyjaśnić, bo ludzie zakładają inaczej: przełączanie między przestrzeniami (Spaces) macOS na tym samym monitorze zawsze działało. Przechwytywanie odbywa się na poziomie ekranu — chwyta to, co jest widoczne na wybranym ekranie. Błąd nigdy nie dotyczył przestrzeni. Zawsze chodziło o wybór złego fizycznego ekranu.
Poprawka, która wyglądała oczywiście — a była błędna
Właściwy sygnał wydaje się prosty: przechwyć ekran, na którym jest użytkownik. Nasza pierwsza implementacja zakotwiczyła się na oknie nakładki GeekBye — przechwytuj ten ekran, na którym żyje nakładka.
Code review słusznie ją zabiło. Nakładka GeekBye jest tworzona jako okno na pełen obszar roboczy na ekranie głównym, w pozycji (0,0). Przenosi się na inny monitor tylko wtedy, gdy fizycznie przeciągniesz tam jej pigułkę — a skróty klawiszowe, które ją przesuwają, przycinają się do wymiarów ekranu głównego, więc nie mogą przenieść jej na drugi monitor w ogóle. Zakotwiczenie przechwytywania na nakładce oznaczało: dla każdego użytkownika, który akurat nie przeciągnął nakładki na swój roboczy ekran, "poprawka" rozwiązywała się z powrotem do ekranu głównego. Nie naprawiłaby prawie nikogo — a przy szybkim teście na jednomonitorowej maszynie deweloperskiej wyglądałaby, jakby działała.
Właściwym punktem zaczepienia jest kursor. Gdziekolwiek jest Twoja mysz, tam jest ekran, na którym pracujesz — i jest to poprawne dla każdego sposobu rozpoczęcia przechwytywania: skrót klawiszowy wyzwala się tam, gdzie wskazujesz, a kliknięcie przycisku Nagrywaj z definicji stawia kursor na tym ekranie. Ostateczna poprawka to dwuwierszowa funkcja: ekran najbliższy kursorowi. Wideo dopasowuje swoje źródło przechwytywania do id tego ekranu; zrzuty przekazują granice tego ekranu do screencapture -R (konkretny prostokąt) zamiast flagi -m (tylko ekran główny).
Świadomie wybraliśmy -R (jawny prostokąt w globalnych współrzędnych ekranu) zamiast -D (indeks ekranu): indeks ekranu w systemie nie ma gwarantowanego związku z kolejnością ekranów we frameworku, więc indeks byłby drugą grą w zgadywanie. Prostokąt z rzeczywistych granic ekranu jest jednoznaczny — a zachowanie flagi zweryfikowaliśmy, łącznie z ujemnymi współrzędnymi dla ekranów umieszczonych na lewo od głównego, na prawdziwym zestawie wielomonitorowym przed wydaniem.
Dlaczego to dobry błąd dydaktyczny
- "Przechwyć ekran" ukrywa decyzję. Na jednym ekranie nie ma decyzji, więc decyzja nigdy nie zostaje zaprojektowana — zostaje domyślnie ustawiona. Wiele monitorów to miejsce, gdzie wychodzi na jaw każdy niejawny domyślny wybór.
- Ciche-złe jest gorsze niż widocznie-złe. Błąd wideo irytował ludzi. Błąd zrzutu wprowadzał w błąd AI, niewidzialnie. Gdy budujesz funkcje, które zasilają model kontekstem, złe wejście produkuje pewnie błędne wyjście bez żadnego błędu nigdzie. To właśnie te awarie warto tropić najzacieklej.
- Poprawka, która przechodzi na Twojej maszynie, może zawieść na każdej innej. Wersja zakotwiczona na nakładce działała w teście jednomonitorowym. Całym sensem tego błędu jest wiele monitorów — a recenzent zastanowił się nad rzeczywistą pozycją okna, zamiast ufać zielonemu testowi. Review to nie pieczątka na działającym kodzie; to drugi model tego, dlaczego kod działa.
GeekBye v2.0.10 dostarcza opartą na kursorze poprawkę zarówno dla nagrywania, jak i zrzutów. Jeśli używasz wielu ekranów, przechwytywanie teraz podąża za Tobą.
Sąsiednie wydania z tej serii znajdziesz w dlaczego Twój notatnik AI przerywa nagrywanie w trakcie spotkania (v2.0.9) oraz dlaczego transkrypcja AI przekręca terminy techniczne (v2.0.11). O tym, jak nakładka zachowuje się podczas połączeń, przeczytasz w jak pozostać niewidzialnym podczas udostępniania ekranu.