Wmaker Cyaneus

Para resolver o problema do gerenciamento de dispositivos como, por exemplo, pendrives, foi criado o wmVolMan. Aqui temos um tutorial de Daniel do Amaral Rodrigues dizendo como instalar o wmVolMan. Este tutorial foi publicado pelo Daniel na lista de discussão do Window Maker.

A instalação do wmvolman requer um nível moderado de conhecimento das entranhas do Linux, e uma boa parte varia de distribuição para distribuição. O que cito a seguir deve ser válido para o Gentoo e descendentes, como o Sabayon, o Kororaa, o Vidalinux e o brazuca Litrix.

1) Baixar o código-fonte da página http://people.altlinux.ru/~raorn/wmvolman.html para um diretório conhecido, desempacote-

o ('tar -jxf wmvolman-0.8.tar.bz2 ') e rode o './configure && make' no diretório gerado. Dependendo da distribuição, podem estar faltando bibliotecas ou cabeçalhos (include files) necessários; eu sei que a libDockApp é necessária, então caso a compilação falhe baixe-a de acordo com sua distribuição, ex. 'emerge -a libdockapp'. Usuários de distribuições binárias devem baixar os cabeçalhos em separado, p. ex. 'apt-get install libdockapp-dev' no Debian e amigos. Note que será necessário acesso de superusuário para instalar programas!

Tendo o programa compilado sem maiores problemas, mude o console para modo de administrador com o comando 'su' e digite 'make install'. Isto deve instalar o programa na sua máquina, mas provavelmente neste ponto se você rodar o wmvolman nenhum dispositivo aparecerá em momento nenhum; precisamos avisar ao daemon de camada de abstração de hardware (hald) para avisar ao nosso programa sobre as mudanças de dispositivo.

Primeiro, veja se o hald está rodando com um 'ps -A | grep hald'. Caso não apareça nada, precisamos verificar que o dbus e o hald estejam instalados e sejam adicionados à seqüência de inicialização; na grande maioria das distribuições modernas, eles já estão lá. No caso da gentoo, o comando é 'emerge -a hal', e para adicionar à inicialização é 'rc-update add dbus default && rc-update add hald default'. Na maior parte das outras distribuições existe um arquivo chamado /etc/rc.local ou /etc/rc.M; adicione as linhas '/etc/init.d/dbus start' e '/etc/init.d/hald start' a esse arquivo após verificar que os arquivos necessários estão instalados.

Finalmente, é preciso passar o arquivo .fdi que o 'make install' instalou em '/etc/hal/fdi/policy/30-wmvolman.fdi' para o diretório onde o hald espera que esses arquivos estejam, que no caso do Gentoo é '/usr/share/hal/fdi/policy/', portanto digite um 'cp /etc/hal/fdi/policy/30- wmvolman.fdi /usr/share/hal/fdi/policy/'. No caso de outras distribuições, ache o diretório correto com um 'find / -iname "*.fdi"' ; use só a parte até 'policy'.

Já deve estar funcionando, mas execute '/etc/init.d/hald restart' por desencargo de consciência. Em seguida, rode o wmvolman e plugue um pen-drive ou um CD e veja se o bichinho responde.

Quem conseguir fazer funcionar com outras distribuições, por favor postar aqui os comandos de instalação e os diretórios, para eu poder fazer um guia mais genérico

-Daniel

Um problema no Window Maker foi identificado por Carlos Mafra, que o relatou em um comentário aqui no blog. Antes de mais nada, não precisamos entrar em pânico, pois não é um bug de segurança, mas de performance. Aqui vai parte do comentário onde o Carlos descreveu o problema:

Usando o programa powertop da Intel eu descobri que o wmaker acorda o meu processador 4 vezes por segundo, mesmo sem eu estar fazendo nada. Um cara da lista do powertop me disse (em email particular) que isso provavelmente é um bug (o Gnome não gera wakeups quando está idle, por exemplo). Eu estava tentando ler o código-fonte pra descobrir o culpado, e acabei encontrando algumas referências a wusleep(), mas nenhuma delas me pareceu ser o motivo dos wakeups. Eu já tentei mandar um email para a lista wm-dev, mas ela está fora do ar. Já tentei mandar email para o Kojima e Dan Pascu, mas até agora nada (se bem que mandei há menos de um dia). Por isso gostaria de iniciar uma discussão sobre isso.

Ontem à noite (e só li hoje) o Carlos me enviou um e-mail relatando sobre a correção para o problema e disponibilizando um patch. Segue o e-mail que me enviou:

O patch para o Window Maker está na minha "página": ttp://www.ift.unesp.br/users/crmafra/patch_wmaker-0.92.0-m2

Ele faz duas coisas:

1. Retira os timers que estavam causando problema (veja as linhas apagadas que contém WMAddTimerHandler);
2. Introduz uma nova funcionalidade, agora quando você muda alguma configuração modificando algum arquivo dentro de GNUstep/Defaults, o wmaker é notificado que houve mudança e as carrega automaticamente.

O meu laptop está funcionando há bastante tempo com o wmaker aberto e não tive qualquer problema. Gostaria que mais pessoas testassem o patch, e é
realmente uma pena que a lista de discussão oficial do wmaker está fora do ar e
nenhum desenvolvedor parece estar mais vivo.

A modificação 2 é relativamente tranquila. Ela utiliza o mecanismo dnotify do kernel para "avisar" sobre mudanças em arquivos. Eu copiei e adaptei o
código-exemplo que está no linux kernel em Documentation/dnotify.txt.

Antes o wmaker adicionava um "timer", que era executado a cada 3 segundos para ver se alguma coisa tinha mudado. Esse é um comportamento ruim, porque acorda a cpu para não fazer nada a maior parte do tempo. Essa era uma das causas do powertop indicar que o wmaker acordava a cpu mesmo estando sem fazer nada. Apesar de no código estar que era executado a cada 3000 milisegundos, nos testes que eu fiz ele era responsável por 0.6 wakeups/segundo. É possível ver isso também sem o patch, usando a opção --no-polling.

A mudança 1 é um pouco difícil. Eu ainda não entendo direito porque nada de ruim acontece ao se retirar o timer que executava "delayedAction" a cada 500 milisegundos. Esse era o maior responsável pelos wakeups apontados pelo powertop. Me parece que essa parte do código não fazia nada importante, ela era executada enquanto não acontecia nada no X (nenhuma tecla apertada, nenhum movimento do mouse, etc). Mas não tenho certeza disso e o melhor seria falar com um desenvolvedor do wmaker. No entanto, posso garantir que no meu computador tudo está funcionando direito!

Todavia, esse patch deve ser tomado "cum grano salis", porque não sou programador e há 5 dias ainda nunca tinha lido o código-fonte do Window Maker.

Carlos R. Mafra

Agradeço ao Carlos Mafra por ter me comunicado isso tudo. Tomei a liberdade de publicar aqui mesmo uma cópia do patch, que continua também disponível na página do Carlos.

Não apliquei o patch, mesmo porque utilizo o Window Maker fornecido diretamente pelo Debian Lenny e nunca tentei compilá-lo eu mesmo. Talvez um outro dia eu faça isso. Segundo o Carlos, com a correção o Window Maker passa a ser responsável por 0 wakeups. Bom, quem quiser testar por favor comente aqui as impressões.

P.S.: A imagem que ilustra este post é do tema para Window Maker Sleep.

Data do início de 2004 um artigo ensinando como adicionar suporte a menus transparentes no Window Maker. O artigo foi escrito por Ricardo Iramar dos Santos, que descreve o procedimento para a versão 0.80.2 do Window Maker.

Não cheguei a testar o recurso e não sei se há de funcionar na versão corrente (0.92.0), mas fica a dica. Quem já testou, quiser testar ou tiver mais informações, fique à vontade!

• Menu Transparente no Window Maker 0.80.2
  

É possível também fazer com que os programas em GTK2 se comportem com tema diferente daquele padrão, sem recorrer ao gnome-settings-daemon.

Para isso você precisa criar um arquivo chamado .gtkrc-2.0 dentro do seu diretório pessoal. Nele, coloque o comando abaixo:

include "/blah/gtkrc"

No lugar de /blah/gtkrc você deve colocar o endereço exato para o arquivo gtkrc do tema que você quer para GTK2. Por exemplo, se você estiver utilizando o usuário heavy com home em /home/heavy e instalou localmente o tema GTK2-Step, para usá-lo o comando seria:

include "/home/heavy/.themes/GTK2-Step/gtk-2.0/gtkrc"

Só não é tão simples ficar mudando o tema, mas para resolver isso estou preparando um truque aqui e depois publico... ;-)