Porque É Que a Gravação de Ecrã Captura o Monitor Errado (e a Nossa Correção)
Numa configuração de dois monitores, o GeekBye gravava e fazia capturas do ecrã principal, não importa em que monitor estivesse a trabalhar. A correção foi uma pequena função — mas a primeira versão estava errada, e a code review descobriu porquê.
Este é um bug que só existe se tiver dois monitores — foi por isso que viveu sossegado durante algum tempo. Trabalha no seu ecrã lateral, inicia uma gravação do GeekBye, e ele grava o seu monitor principal. O da barra de menus. Aquele para o qual não estava a olhar.
O mesmo defeito, mais silencioso e pior, atingia as capturas de ecrã que o GeekBye envia à IA para dar contexto: prime o atalho de captura no seu segundo monitor e a IA recebe uma imagem do primeiro. Não há qualquer sinal visual — o assistente limita-se a responder sobre o ecrã errado e você fica a perguntar-se porque está confuso. O GeekBye v2.0.10 corrigiu ambos.
Dois pipelines, um mesmo valor por omissão preguiçoso
A captura de ecrã no desktop são dois caminhos de código separados, e ambos tinham escolhido por conta própria o ecrã principal:
- A gravação de vídeo enumerava as fontes de ecrã disponíveis e pegava na primeira —
sources[0]. No macOS isso é, na prática, sempre o ecrã principal. Sem seletor, sem qualquer lógica sobre onde estava de facto. O comentário no nosso próprio código dizia literalmente "auto-select first screen source." - As capturas de ecrã usavam o comando
screencapturedo macOS com o flag-m. Esse flag tem exatamente um significado: apenas ecrã principal. Fixo no código.
Nenhum dos caminhos fazia alguma vez a pergunta que importa: em que ecrã está o utilizador?
Uma coisa que nunca esteve avariada, e vale a pena esclarecer porque as pessoas presumem que sim: alternar entre Spaces do macOS no mesmo monitor sempre funcionou. A captura acontece ao nível do ecrã — agarra o Space que estiver visível no ecrã escolhido. O bug nunca foi sobre os Spaces. Foi sempre sobre escolher o ecrã físico errado.
A correção que parecia óbvia — e estava errada
O sinal correto parece fácil: capturar o ecrã em que o utilizador está. A nossa primeira implementação ancorou-se na janela do overlay do GeekBye — capturar o ecrã em que o overlay vive.
A code review matou-a, e com razão. O overlay do GeekBye é criado como uma janela de área de trabalho completa no ecrã principal, na posição (0,0). Só se move para outro monitor se arrastar fisicamente a sua pílula para lá — e os atalhos de teclado que o empurram limitam-se às dimensões do ecrã principal, por isso não podem de todo movê-lo para um segundo monitor. Ancorar a captura no overlay significava: para cada utilizador que não arrastasse por acaso o overlay para o seu ecrã de trabalho, a "correção" resolvia de volta para o ecrã principal. Não teria corrigido quase ninguém — enquanto parecia, num teste rápido numa máquina de desenvolvimento de um único monitor, que funcionava.
A âncora certa é o cursor. Onde estiver o seu rato, é esse o ecrã em que está a trabalhar — e é correto para cada forma como uma captura arranca: um atalho de teclado dispara onde está a apontar, e clicar no botão Gravar coloca o seu cursor nesse ecrã por definição. A correção final é uma função de duas linhas: o ecrã mais próximo do cursor. O vídeo faz corresponder a sua fonte de captura ao id desse ecrã; as capturas passam os limites desse ecrã a screencapture -R (um retângulo específico) em vez do flag -m de ecrã principal.
Escolhemos -R (um retângulo explícito em coordenadas globais de ecrã) em vez de -D (um índice de ecrã) deliberadamente: o índice de ecrã do sistema operativo não tem correspondência garantida com a ordenação de ecrãs do framework, por isso um índice seria um segundo jogo de adivinha. Um retângulo a partir dos limites reais do ecrã é inequívoco — e verificámos o comportamento do flag, incluindo coordenadas negativas para ecrãs colocados à esquerda do principal, num equipamento multi-monitor real antes de lançar.
Porque é que este é um bom bug para aprender
- "Capturar o ecrã" esconde uma decisão. Num único ecrã não há decisão, por isso a decisão nunca é desenhada — é assumida por omissão. O multi-monitor é onde cada valor por omissão implícito vem ao de cima.
- Errar em silêncio é pior do que errar à vista. O bug do vídeo irritava as pessoas. O bug das capturas enganava a IA, de forma invisível. Quando constrói funcionalidades que alimentam contexto a um modelo, uma entrada errada produz uma saída errada com toda a confiança e sem qualquer erro em lado nenhum. Essas são as falhas que mais vale a pena caçar.
- Uma correção que passa na sua máquina pode falhar na de toda a gente. A versão ancorada no overlay funcionava num teste de um único monitor. Todo o sentido do bug são os múltiplos monitores — e o revisor raciocinou sobre a posição real da janela em vez de confiar no teste verde. A revisão não é um carimbo sobre código que funciona; é um segundo modelo do porquê de o código funcionar.
O GeekBye v2.0.10 traz a correção baseada no cursor tanto para a gravação como para as capturas. Se usa vários ecrãs, a captura agora segue-o.
Para os lançamentos vizinhos desta série, veja porque é que o seu notetaker com IA para de gravar a meio da reunião (v2.0.9) e porque a transcrição com IA ouve mal os termos técnicos (v2.0.11). Sobre como o overlay se comporta durante as chamadas, veja como manter-se invisível durante a partilha de ecrã.
