O leitor André Luís Lopes (andrelopes@albnet.com.br) enviou este texto sobre a acentuação no Conectiva Linux 5.0, que se adapta facilmente a outras versões da distribuição da Conectiva, e também a outras derivadas da Red Hat. Incidentalmente ele inclui noções profundas sobre o processo de carregamento do X, e portanto faz de sua dica uma leitura interessante até mesmo para quem já sabe configurar acentuação....
IMPORTANTE : Os procedimentos aqui citados foram testados em uma máquina rodando Conectiva Linux 4.0 e aplicam-se a esta mesma distribuição .
Você pode ter alguns problemas ao tentar utilizar corretamente a acentuação em outros gerenciadores de janelas diferentes do WindowMaker e do KDE . Nota: O KDE não é um gerenciador de janelas . Na verdade ele é um gerenciador de desktop (desktop manager) e traz um gerenciador de janelas - até o versão 1.1.2 , o kwm - o qual , geralmente , é utilizado em conjunto com o mesmo. No caso , tive problemas em conseguir a acentuação a partir do IceWM . Para contornar o problema estudei um pouco os arquivos de inicialização do XFree86 e consegui resolver o problema .
O xinit , um dos programas responsáveis pela inicialização do ambiente gráfico Linux , executa o script xinitrc para ajustar opções de acentuação no idioma correto e também procura pelo arquivo Xclients , onde são definidas as opções de gerenciadores de janelas que podem ser executados - os clientes X que se conectarão ao servidor X .
O xinitrc invoca o utilitário xmodmap passando como parâmetro o nome do arquivo modificador de mapas de teclas que deve ser utilizado para utilização de acentuação dentro do ambiente gráfico . No caso da distribuição Conectiva Linux 4.0 existem dentro do diretório /etc/X11/xinit uma série de arquivos modificadores de mapas de teclas. Por exemplo , o Xmodmap.abnt2 para teclados padrão ABNT2 , Xmodmap.us+ para teclados padrão americano internacional - U.S. International - e diversos outros .
O nosso problema reside no fato de que caso tentemos executar o gerenciador de janelas desejado de uma outra forma diferente do forma padrão , ou seja , sem a utilização do startx , teremos uma quantidade muito maior de trabalho do que se estivéssemos usando a forma padrão . Isto porque o startx é um script que realiza boa parte do trabalho sujo automaticamente , como por exemplo , a chamada correta do xinit , passando os argumentos corretos colhidos com base na verificação da configuração específica dos arquivos de configuração do xinit e até a execução do xauth para inclusão dos hosts com permissão de conexão ao servidor X . Consulte o arquivo /usr/X11R6/bin/startx para checar com detalhes o que o startx automatiza .
Como a utilização do startx simplifica em muito nosso trabalho e é o ponto de partida para a execução dos demais scripts de inicialização do ambiente gráfico , é importante que possamos iniciar o gerenciador de janelas de nossa preferência utilizando-o , pois estando o startx funcionando corretamente poderemos , sem maiores dificuldades , estar automatizando a chamada ao xinit e consequentemente ao xinitrc , o qual por sua vez cuidará da tarefa de fazer a chamada apropriada ao xmodmap passando o modificador de mapas de teclado correto como parâmetro , permitindo a correta acentuação no ambiente gráfico . que é na verdade o que queremos . Iniciar o startx com sucesso é possível caso queiramos usar o WindowMaker , gerenciador de janelas padrão na distribuição Conectiva Linux 4.0 , mas caso resolvamos utilizar um gerenciador de janelas alternativo , teremos um pequeno mas compensador trabalho .
Em seguida , focarei a explicação com o objetivo de conseguirmos iniciar qualquer gerenciador de janelas desejado a partir do startx . Uma interessante observação sobre o KDE é que , apesar do mesmo oferecer um script próprio para incialização do ambiente gráfico - kdeinitrc - os procedimentos indicados a seguir também são válidos para o mesmo .
Sobre a escolha do gerenciador de janelas padrão , é feita uma procura em um arquivo tentando encontrar o gerenciador de janelas preferido e caso não seja possível encontrá-lo no arquivo em questão , o WindowMaker é executado . Caso o WindowMaker não exista na máquina , é tentado então o fvwm e por último o twm . Como o WindowMaker é fornecido por padrão com a distribuição da Conectiva ele sempre é iniciado , a não ser , é claro , que o mesmo tenha sido removido do sistema .
No entanto , no interior do arquivo Xclients padrão do sistema existe uma instrução que verifica a presença do arquivo .wm_style no diretório HOME do usuário atual . É no interior deste arquivo , em apenas uma única e simples linha , que é definido o gerenciador de janelas padrão do usuário . Caso você nunca tenha alterado seu arquivo .wm_style , verifique e o mesmo deve conter em sua primeira linha a palavra WindowMaker . Mude esta palavra para , por exemplo , icewm e toda vez que for informado startx no console do sistema o IceWM será carregado como seu gerenciador de janelas padrão . Isso permite que cada usuário cadastrado no sistema possa rodar seu gerenciador de janelas preferido a partir do console executando somente o comando startx , visto que para tanto seria necessário somente colocar o nome do gerenciador de preferência no arquivo acima citado .
Em alguns casos , é possível executar um gerenciador de janelas informando apenas o nome de seu executável principal no console (no caso do WindowMaker , é possível excutá-lo rodando apenas o executável wmaker) , mas no caso do IceWM , por exemplo , não existe essa possibilidade . No caso , podem ocorrer problemas com o definição da variável DISPLAY e , mesmo depois da definição correta da mesma , problemas podem continuar a ocorrer , como a impossibilidade de conexão com o servidor X .
Gostaria de frisar que encontrei outras formas de mudar o gerenciador de janelas padrão do sistema , mas esta se mostrou a mais fácil de ser executada .
Adicionalmente , para um ambiente onde exista uma quantidade muito grande de usuários que utilizam a mesma máquina ou para ambientes de rede onde o diretório HOME dos usuários é centralizado em um servidor e o mesmo é acessado via rede (geralmente via NFS) , formas de automatização poderiam ser consideradas para a realização desta tarefa , como a criação de scripts que editariam os arquivos .wm_style dos usuários definindo o gerenciador de janelas desejado pelo administrador da rede .
Também poderiam ser pensadas maneiras de mudar o gerenciador de janelas de usuários baseando-se em informações de grupos dos usuários (GUID , por exemplo) . Por exemplo , o grupo de usuários do Departamento Gráfico pode ter um gerenciador de janelas mais pesado , mas que ofereceça maiores recursos , uma vez que , geralmente , estes usuários trabalham com máquinas mais velozes . Os usuários que não necessitem de nada muito mais complexo do que uma simples composição de textos , podem liberar um pouco mais de memória para o sistema rodando gerenciadores de janelas leves , que não oferecem muitos recursos , mas que são suficientes para o tipo de tarefa que executam.
Enfim , existem muitas situações onde o controle da execução dos gerenciadores de janelas seria interessante e poder executá-los corretamente com a adequação ao idioma em uso é uma boa .
Este artigo foi escrito por André Luís Lopes (andrelopes@albnet.com.br) e pode ser reproduzido livremente desde que sejam mantidos os devidos créditos .
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.