LPC: 25 years of X
Autor original: Jonathan Corbet
Publicado originalmente no:
lwn.net
Tradução: Roberto Bechtlufft

O X Window System completou 25 anos discretamente em junho; sem dúvidas, o X é um dos projetos de software livre mais antigos e bem sucedidos em atividade. Pela maior parte desse tempo, Keith Packard tem trabalhado no X; na Linux Plumbers Conference em Portland, Estados Unidos, ele aproveitou sua apresentação para destacar os altos e baixos desses 25 anos, e algumas das lições que foram aprendidas.

15cd7b61

O X11 é a versão do X que conhecemos hoje. Houve nove versões anteriores a essa (uma foi ignorada), mas o X10, de 1986, foi a primeira versão a realmente se difundir. As empresas o distribuíram, os fornecedores que formavam o Consórcio X começavam a pensar que seu trabalho estava concluído, mas os desenvolvedores do X insistiram na criação de mais um “pequeno” conjunto de revisões ao protocolo do X. O resultado foi o X11, uma completa recriação do sistema inteiro, lançado em 15 de setembro de 1987, e que continua em atividade até hoje.

Muitas ideias novas surgiram no X11, e umas faziam mais sentido do que outras. Uma delas era essa ideia de um gerenciador de janelas externo. No X, o gerenciador de janelas é só mais um processo trabalhando com a mesma API. Essa abordagem ajudou a criar uma API consistente entre as janelas, e também tornou possível gerenciar aplicativos que paravam de responder de uma forma que outros sistemas ainda não conseguem replicar. Por outro lado, o gerenciador de janelas externo fazia a tela piscar um bocado, um problema que ainda hoje aparece de vez em quando, e não funciona perfeitamente com as técnicas modernas de composição, atrapalhando as operações de troca de página necessárias para acelerar as coisas.

O uso de seleções para operações de recortar e colar foi outra inovação do início do X11. Com as seleções, a origem dos dados selecionados anuncia sua disponibilidade, e o destino solicita esses dados no formato desejado. Esse mecanismo permite que os dados sejam selecionados e movidos entre aplicativos em quase qualquer formato. Infelizmente o conceito do “buffer de recorte” permaneceu, e os aplicativos tiveram que dar suporte aos dois modos; a longa demora do Emacs para começar a usar as seleções não ajudou muito. A existência de várias seleções criou problemas de interoperabilidade entre os aplicativos. Por outro lado, o mecanismo de seleção mostrou-se uma ótima base para interfaces de arrastar e soltar, e lidou com a transição para o Unicode com facilidade.

A questão da entrada foi fonte de inúmeros problemas. A exigência de que aplicativos especifiquem quais eventos desejam fazia sentido quando o foco estava em tentar fazer o melhor uso possível de uma conexão de rede, mas levou a algumas alterações de comportamento interessantes dependendo de como os aplicativos selecionavam seus eventos. A ideia do X era a de ser um sistema sem diretivas, mas fazendo uma retrospectiva, as regras para entrega de eventos constituíam uma quantidade significativa de diretivas amarradas aos níveis mais baixos do sistema.

As capturas (“grabs”), através das quais um aplicativo podia solicitar a entrega exclusiva de eventos específicos, eram um caso típico. As “capturas passivas” permitiam que os gerenciadores de janelas criassem vínculos com teclas específicas (por exemplo, ao usar alt + botão do meio para redimensionar uma janela), mas exigiam uma diretiva de “a janela pai tem preferência” quando essas capturas eram usadas. As “capturas sincrônicas” eram piores ainda. Seu objetivo era o de ajudar a criar interfaces que respondessem rapidamente mesmo diante de redes e aplicativos lentos; clicar em uma janela e começar a digitar teria o efeito certo, mesmo se o sistema demorasse a responder ao clique e a atribuir o foco do teclado. Era um sistema complicado, era difícil programar para ele e ainda mais difícil de se testar, além de exigir um armazenamento de eventos potencialmente infinito no servidor X. E isso tudo é desnecessário; hoje em dia, nenhum aplicativo faz uso dessas coisas. O “recurso” só congestiona o caminho para recursos mais úteis, como o redirecionamento de eventos; é provável que precise ser removido, mesmo que isso quebre o protocolo do X11.

A entrada de texto também tinha lá os seus próprios problemas; o X fazia tinha um trabalhão para descrever o que estava escrito em cada tecla, e exigia que os aplicativos lidassem com os detalhes como os mapeamentos do teclado e as teclas modificadoras. As coisas funcionavam razoavelmente bem para a entrada de texto em inglês, mas ia muito mal quando eram usados idiomas asiáticos. A inclusão da camada de internacionalização XIM não ajudou muito; ela foi enfiada na biblioteca Xlib e exigia que os aplicativos fossem reescritos. Ela também forçava a instalação de um conjunto bem grande de fontes, ainda que a maioria delas nunca tivesse que ser usada.

A saída de texto era um “desastre ainda maior”. Ela exigia que as fontes estivessem no servidor; os aplicativos tinham que puxar grandes conjuntos de medidas de fontes para serem iniciados. Isso já era bastante ruim, mas a geração das medidas das fontes exigia que o servidor armazenasse como imagens todos os glifos, o que não tornava a manipulação de fontes asiáticas muito divertida. Adicionar fontes ao sistema era uma chatice, e o Unicode “nunca aconteceu” nesse subsistema. Hoje, olhando para trás, diz Keith, o fato de que nem o FrameMaker nem o Xdvi (os dois aplicativos que tentavam lidar de maneira séria com a saída de texto na época) usavam o mecanismo de fontes do X já era um alerta óbvio de que havia algo errado.

Para lidar com esse problema, o gerenciamento das fontes poderia poderia ter sido movido para os clientes (como acabou acontecendo mais tarde), só que, em vez disso, criou-se uma enorme leva de gatilhos. Surgiram os servidores de fontes, que poupariam espaço e facilitariam a inclusão de fontes. O mecanismo XLFD (descrição lógica de fontes do X) pôs no mundo nomes de fontes como:

-adobe-courier-medium-r-normal–14-100-100-100-m-90-iso8859-1

e não facilitou a vida de ninguém. O mecanismo de texto composto chegou ao iso-2022, mas não era capaz de lidar com o Unicode — e mais uma vez, exigia que os aplicativos fossem reescritos.

O modelo usado pelo X para desenhar também tinha problemas divertidos. Ele foi criado para ser um “PostScript light”, mas para chegar lá, abriu mão de pequenos conceitos como caminhos, splines e transformações, e exigia o uso de canetas circulares. Ou seja, não sobrou muita coisa do PostScript. Esse modelo exigia pixelização precisa, exceto quando linhas “finas” de largura zero eram usadas — só que todos os aplicativos acabavam usando linhas finas. A pixelização precisa era um conceito legal, e ela podia ser testada com facilidade, mas era terrivelmente lenta na prática.

O uso de canetas circulares gerava ainda mais transtornos; a ideia foi tirada do “Livro Vermelho” do PostScript, mas na época, a turma do PostScript já tinha percebido que era difícil trabalhar com esse recurso e já havia contornado o problema. Uma linha desenhada com uma caneta circular, na ausência do antialiasing, tende a variar em largura, ficando meio disforme. A geração dessas linhas também exigia o cálculo de raízes quadradas no servidor, e essa não era uma boa maneira de se conseguir um bom desempenho. A equipe do PostScript já tinha descoberto uma maneira de usar as canetas circulares da maneira certa, só que ninguém da equipe do X sabia disso, e o X acabou não se beneficiando.

715b9227

Em vez de proporcionar splines, o protocolo do X11 permitia o desenho de elipses. Mas havia uma pegadinha: as elipses precisavam estar alinhadas ao eixo X ou ao eixo Y, elipses diagonais não eram permitidas. Havia um motivo para isso: corria um boato de que o desenho de elipses não alinhadas a um eixo envolvia um algoritmo patenteado, e pelos motivos de sempre, ninguém quis conferir a história. Acontece que o tal método havia sido publicado em 1967, e qualquer patente que possa ter existido já teria perdido a validade. Só que ninguém sabia disso, porque ninguém estava disposto a correr os riscos envolvidos na pesquisa da suposta patente; as patentes de software já criavam problemas na década de 80.

Para completar, a combinação de elipses e canetas circulares exigia a avaliação de equações de quarto grau. Era preciso usar aritmética de 128 bits para lidar bem com isso; números de ponto flutuante de 64 bits não davam conta.

O gerenciamento de cores foi encaixado mais tarde; sim, ele também foi enfiado na “pequena e leve” camada Xlib. Ele proporcionava várias bases legais para o uso de cores no espaço de cores CIE, embora os usuários geralmente prefiram identificar as cores com nomes como “vermelho”. Ou seja, ninguém nem usou os recursos do espaço de cores. E o código do “gerenciamento de cores” só funcionava no X; não havia mecanismo para correspondência das cores na saída para meta-arquivos gráficos ou impressoras. O gerenciamento de cores do X nunca foi muito popular.

Apesar de todos esses erros, não se deve ignorar o sucesso do X como software livre.

O X saiu alguns anos antes da primeira versão da GPL. Depois que a GPL saiu, Richard Stallman passou a visitar regularmente os escritórios do Consórcio X; ele pedia, daquele jeito persistente que ele tem, que o X mudasse de licença. Mas essa opção não era viável; o Consórcio X era apoiado por um grupo de corporações que estava plenamente satisfeito com a licença MIT. Mas analisando as coisas, diz Keith, “Richard tinha razão”.

O X era um projeto apoiado pela indústria, aberto a “todos menos à Sun”. O domínio da Sun no mercado de estações de trabalho na época intimidava os fornecedores; elas achavam que, se pudessem desbancar o SunView com uma alternativa que se tornasse padrão da indústria, teriam mais facilidade para entrar nesse mercado. Jim Gettys vendeu essa ideia, praticamente sozinho, para a Digital Equipment Corporation; essa pode ter sido a primeira tentativa do software livre de tomar um mercado já existente. E funcionou: esses fornecedores acabaram com o trunfo que a Sun tinha nesse mercado, e talvez, como observou Keith, no mercado de estações de trabalho Unix como um todo.

Obviamente, havia alguns problemas. A licença MIT desencoraja o compartilhamento de código, e por isso todos os fornecedores pegavam o código do X e criavam seu próprio fork fechado. Nunca acontecia de um patch voltar desses fornecedores para a versão livre do X. Além disso, embora a implementação do X11 fosse feita principalmente na Digital Equipment Corporation, a manutenção do código era atribuída ao Consórcio X no MIT. Naquele momento, diz Keith, toda a inovação no X simplesmente parou. Os projetos que vinham do Consórcio X nessa época eram invariavelmente fracassos absolutos: XIE, PEX, XIM, XCMS etc. Ali teve início um período negro e duradouro, no qual o X ficou basicamente estagnado.

O X não está mais estagnado; seu desenvolvimento segue fortíssimo no freedesktop.org. Como o X voltou à vida, seus desenvolvedores tiveram que fazer uma baita limpeza no código. Keith bolou um método seguro para remover a bagagem inútil da base de código antiga. As etapas descritas por ele eram estas:

  1. Publique uma especificação de protocolo e prometa que haverá suporte a longo prazo.
  2. Perceba que você fracassou.
  3. Quebre as coisas “acidentalmente” no código.
  4. Deixe alguns anos passarem, e observe que ninguém reclamou dos recursos afetados pela quebradeira.
  5. Remova o código, já que obviamente ninguém está fazendo uso dele.

Seguindo esse modelo, o subsistema XCMS passou cinco anos quebrado sem que ninguém reclamasse. Recentemente, descobriu-se que o código do DGA também está quebrado há cinco anos. A técnica funciona, e Keith encoraja seu público a “ir em frente e criar uns bugs”.

A conclusão mais importante, porém, é a de que após 25 anos, o X continua vivo e forte. Ele ainda oferece suporte a aplicativos com mais de 20 anos de idade. Poucos projetos de software livre podem dizer isso. Com todos os seus defeitos, gatilhos e problemas, o X Window System é um sucesso evidente.

Créditos a Jonathan Corbet – lwn.net
Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>

Fonte:  Guia do Hardware: http://www.guiadohardware.net/artigos/25-anos_x/

Anúncios