Wmaker Cyaneus

2.1 Por que não são mostrados ícones após a instalação do Window Maker?

A partir da versão 0.15.0 do Window Maker, a configuração de fábrica inclui ícones .tiff, o que requer que você compile o Window Maker com suporte a libtiff. Para ajuda na compilação da libtiff, veja a próxima questão.

2.2 Como faço para vincular o Window Maker ao libtiff?

Muitos sistemas operacionais UNIX têm dificuldade para encontrar bibliotecas de terceiros na configuração de fábrica. Infelizmente, há muitas para incluir instruções para todas elas.

De modo geral, você desejará garantir que a versão mais recente do libtiff esteja instalada (veja ftp://www.libtiff.org). Tipicamente em sistemas não-Linux, a libtiff se encontrará sob o diretório /usr/local, com arquivos de include e biblioteca em seus subdiretórios correspondentes.

Muitas vezes é necessário adicionar add /usr/local/lib à variável de ambiente LD_LIBRARY_PATH do sistema (especialmente no Solaris, mas consulte "man ld" para ver detalhes referentes à sua plataforma). Ademais, é possível fornecer diretivas especiais para o script de configuração, de modo a ajudá-lo a encontrar as bibliotecas. Um exemplo:

./configure --with-libs-from="-L/usr/local/lib" \
	    --with-incs-from="-I/usr/local/include"

Também, você desejará garantir que está usando o GNU maker (gmake) para compilar o Window Maker.

2.3 Como mudo o gerenciador de janelas para usar o WindowMaker?

Método 1:

Peter Ilberg nos deu esta resposta:

Instale WM onde você quiser, o meu está em /opt/WindowMaker-0.16.0 (por exemplo, use ./configure --prefix=/opt/WindowMaker-0.16.0). Rode o script de instalação wmaker.inst no seu diretório home.

Adicione as duas linhas abaixo ao arquivo .dtprofile no seu diretório home:

SESSIONTYPE=xdm; export SESSIONTYPE
PATH=:/usr/contrib/bin/X11:$PATH:.; export PATH

Isso diz ao CDE para ele buscar por um arquivo .xinitrc/.xsession ao invés de usar o ambiente como vem de fábrica.

Torne seu arquivo .xsession/.xinitrc executável (MUITO IMPORTANTE, wmaker.inst NÃO faz isso automaticamente) usando, por exemplo:

chmod ugo+x .xsession

Seu arquivo .xsession/.xinitrc deve se parecer com isso:

#!/bin/sh
<some other init stuff that you want/need>
exec wmaker

Coisas para tentar se isso não der certo: (um tanto confuso e aleatório)

Tive problemas algumas vezes, que resolvi escrevendo endereços absolutos para wmaker em .xsession/.xinitrc e/ou tornando o dtprofile/.xinitrc/etc executável. Também ajuda entrar no console (selecione a partir da tela de login do CDE) e iniciar o X manualmente usando "X". Se funcionar desta forma, tem que funcionar entrando no ambiente CDE. Lembre-se de verificar seus caminhos (paths)!

Se ainda assim não funcionar, você pode também substituir o wmaker por algum outro gerenciador de janelas no .xinitrc e ver se funciona. Se funcionar, você saberá que pelo menos que o .xinitrc está sendo chamado/executado, assim seu caminho para o WM é que deve estar definido de maneira errada.

Método 2:

Thomas Hanselman deu esta resposta alternativa (via Peter Ilberg):

Construa e instale WM onde quiser, como descrito no Método 1. Você pode instalar e rodar WM de dentro do seu diretório home. É o que eu estou fazendo, uma vez que não tenho acesso de administrador no trabalho :(. Então, no seu arquivo Xdefaults, dentro do seu diretório home, adicione a seguinte linha:

Dtsession*wmStartupCommand: <path to WindowMaker executable>

Então saia e entre novamente e, a menos que eu tenha esquecido algum passo, você deve estar no paraíso do Window Maker ;).

2.4 Eu preciso executar novamente o wmaker.inst para cada nova versão do Window Maker?

Dan Pascu nos dá a resposta:

Se necessário, será informado no arquivo NEWS incluído no código-fonte. A partir da versão 0.15.x, os arquivos de domínio têm sido mudados de modo que executar novamente o wmaker.inst é redundante. Os arquivos de configuração do usuário estão agora mesclados com os arquivos de configuração globais, normalmente localizados em /usr/local/share/WindowMaker/Defaults. Assim, uma vez que novas opções sejam adicionadas, elas serão adicionadas ao ambiente de maneira automática.

2.5 Por que a raíz do meu menu só tem xterm e os ítens de saída?

Mais provável é que o Window Maker não esteja encontrando uma cópia do pré-processador C em um diretório como /lib. O arquivo /lib/cpp deve ser um link simbólico para o compilador cpp que você está utilizando. Por exemplo:

	cpp -> /usr/bin/cpp-2.95*

Outra possibilidade é que seu /usr/X11/lib/X11/xinit/xinitrc seja um link simbólico quebrado. Os comandos abaixo podem funcionar para criar um novo link simbólico ou algo parecido um novo arquivo:

	$ cp /usr/X11/lib/X11/xinit/xinitrc.fvwm2 \
		/usr/X11/lib/X11/xinit/xinitrc.wmaker

	$ ln -sf /usr/X11/lib/X11/xinit/xinitrc.wmaker \
		/usr/X11/lib/X11/xinit/xinitrc

/então edite/usr/X11/lib/X11/xinit/xinitrc e substitua (N.T.: no caso do comando usando "cp") o exec de 'fvwm2' para '/usr/local/bin/wmaker' (deve estar em algum lugar perto do fim do arquivo, mais provavelmente a última linha).

Agradecimentos a Tomas Szepe pela segunda parte.

2.6 Como faço para o Window Maker usar mais que 16 cores na minha estação de trabalho SGI Indy?

Agradecimentos a Peter H. Chou por esta resposta:

Como opção de fábrica, o Servidor X SGI usa modo 8-bit de Pseudocor. Para mudá-lo, edite (como root) o arquivo /usr/lib/X11/xdm/Xservers. Mude-o para ler:

    :0 secure /usr/bin/X11/X -bs -c -class TrueColor -depth 24

2.7 Usando Window Maker com CDE no Solaris 2.6 CDE

Grato a Rob Funk pela resposta:

Assumindo que você instalou o Window Maker de acordo com o arquivo README que acompanha seu código-fonte, tudo o que você precisa fazer para rodar o Window Maker em uma máquina com Solaris é alterar o .xinitrc. Isso deve funcionar em qualquer versão. Quando executar o wmaker.inst pela primeira vez, permita-lhe mudar o arquivo .xinitrc. O meu está mais ou menos assim:

 #!/bin/sh
 # Window Maker Default .xinitrc
 exec /usr/local/bin/wmaker

Acredite ou não, é tudo de que você precisa. Isso, de fato, apenas roda o Window Maker ao invés do OpenWindows. Para escolher o Window Maker, simplesmente escolha "OpenWindows Desktop" no menu "Options - Session" e escolha "CDE Desktop" se você quiser CDE.

O esquema de cores e configurações para o Window Maker é separado do CDE. Eu o testei em um SPARC 10, mas acredito que no Solaris x86 funcione também.

(nota do webmaster: funciona legal no Solaris x86)

2.8 Como instalo o Window Maker no Solaris?

Há algumas dicas de John Kemp:

Instalar Window Maker em uma máquina com Solaris 2.6 pode requerer uma ou duas pequenas dicas. Aqui você está (isso foi num sistema rodando xdm, mas sugestões similares se aplicam a outros casos):

1) /usr/openwin/lib/X11/xdm/Xservers como este:

:0 local /usr/openwin/bin/X -dev /dev/fb defdepth 24 defclass TrueColor

2) Ative shm na configuração do Window Maker:

./configure --disable-shm

3) você pode precisar modificar seu LD_LIBRARY_PATH:, ou tornar "wmaker" um script que faça isso para você (mv wmaker wmaker.exe):

LD_LIBRARY_PATH=/usr/local/lib:/usr/local/X11/lib:/usr/lib:/usr/openwin/lib export LD_LIBRARY_PATH /usr/local/bin/wmaker.exe $*

The real key is the "--disable-shm".

(nota do webmaster: Window Maker deve funcionar bem com SHM ativado, pelo menos rodando no Solaris 8. Tente o padrão primeiro, e então utilize estas dicas se você tiver problemas)

2.9 Como corrijo um erro como libwraster.so.1: cannot open shared object file?

Se ao executar o Window Maker você se depara com um erro parecido com este

libwraster.so.1: cannot open shared object file

Estas são as instruções para GNU/Linux:

Primeiro, assegure-se de que /usr/local/lib (ou o equivalente no diretório onde você instalou o Window Maker) está listado em seu /etc/ld.so.conf. Você precisa rodar ldconfig de modo que as novas bibliotecas compartilhadas possam ser carregadas. Após executar ldconfig como root, o linker deve carregar as bibliotecas apropriadamente. Você precisa rodar isso toda vez que atualizar o Window Maker.

Graças a Joseph Czapiga, o procedimento para BSD para adicionar diretórios de bibliotecas compartilhadas é

ldconfig -m /usr/local/lib (m means merge)

2.10 Como eu corrijo um erro assim - aclocal: configure.in: 15: macro 'AM_PROG_LIBTOOL' not found in library?

Você precisa instalar libtool. Também deve ser uma versão diferente do libtool da versão 1.2b (distribuída com o redhat 5.2). Você pode pegar o libtool em ftp.gnu.org/pub/gnu. Esteja certo de que as versões autoconf e automake que você tem instaladas são pelo menos: autoconf 2.12 automake 1.3 libtool 1.2

De Blaine Horrocks:

"Você pode também contornar esse problema no RedHat5.2 copiando o aclocal.m4 para ainclude.m4 antes de rodar o configure pela primeira vez. Configure funcionará normalmente e fará o make com sucesso."

2.11 Quando eu rodo o wmaker, ele fecha reclamando de '__register_frame_info'

Isso está relacionado com o Window Maker ter sido compilado em um sistema cujas bibliotecas foram compiladas por egcs ou gcc 2.8.0, e então usando os binários em um sistema cujas bibliotecas foram compiladas pelo gcc 2.7.2.x

Tente compilar o Window Maker com a versão mais nova do gcc ou recompilar as bibliotecas do seu sistema com o gcc mais antigo. É geralmente uma má idéia misturar.

2.12 Como eu faço um link com a libjpeg no Window Maker?

A mais nova biblioteca jpeg está disponível em http://www.ijg.org

Quantos de vocês têm visto um erro do tipo "lib reports 62 caller expects 61"? Aqui estão algumas respostas que possivelmente ajudarão.

Antes de qualquer coisa, assegure-se de que não há uma cópia antiga da libjpeg no sistema. Algumas distribuições trazem de fábrica versões antigas da libjpeg.so.1 no diretório /usr/X11R6/lib/. Ela pode ser simplesmente deletada. Ou, se algo reclamar depois da deleção, recompile-a para colocar uma nova versão no lugar certo ou, se isso falhar, como último recurso, você pode adicionar um link simbólico para a nova biblioteca como em: ln -s /usr/local/lib/libjpeg.so.6.0.2 libjpeg.so.1

Note que você deve usar a versão do ldconfig que está no seu sistema para gerenciar de maneira apropriada seu cache de bibliotecas (ou outro mecanismo apropriado).

Em Linux, isso significa ter /usr/local/lib no /etc/ld.so.conf e então rodar ldconfig.

Agora para o erro. Ele é basicamente causado por sua aplicação ter sido compilada para usar dinamicamente a biblioteca compartilhada libjpeg.so. Quando você instala uma nova biblioteca e então tenta rodar seu programa novamente, ele espera a biblioteca em sua compilação anterior, neste caso a antiga libjpeg.so.6.0.1 ao invés da nova libjpeg.so.6.0.2 , então relata o erro.

A correção é atualmente simples. Adicionando um link simbólico libjpeg.so.6 como em (neste caso exato): ln -s libjpeg.so.6.0.2 libjpeg.so.6 onde você instalou sua nova biblioteca, você simplesmente precisa recompilar sua aplicação para vincular à nova biblioteca.

Esteja certo, também, de usar o GNU make para compilar o Window Maker.

2.13 Como eu inicio o Window Maker depois de rodar o wmaker.inst?

A partir da versão 0.53.0, o script wmaker.inst modificará seu script de inicialização X (.xinitrc ou .Xclients ou .Xsession) para fazer o que for apropriado.

Para rodar o wmaker, um usuário precisa ter o arquivo ~/.xinitrc mais ou menos assim:

#!/bin/sh
exec wmaker

Isso varia de sistema para sistema, mas a existência de um arquivo .xinitrc geralmente sobrescreve o que veio com o sistema.

2.14 Como vinculo o libpng com o Window Maker?

A mais recente versão da biblioteca png você encontra em availible at http://www.libpng.org/pub/png/libpng.html

Você também precisa da versão mais recente da zlib, em http://www.gzip.org

Geralmente, as mesmas regras que se aplicam à libjpeg se aplicam aqui. Esteja certo de que não há versões antigas das bibliotecas necessárias no seu sistema, então tente configurá-las e reconstruí-las.

Você também precisa usar o GNU make (gmake) para compilar o Window Maker.

2.15 Como vinculo giflib ou libungif ao Window Maker?

As versões mais novas de ambas as bibliotecas podem ser encontradas em http://prtr-13.ucsc.edu/~badger/software/. Usuários têm tido alguns problemas com a giflib... Parece que o processo de instalação não instala o arquivo de cabeçalho libgif.h, de modo que a configuração do Window Maker não encontra a biblioteca (libgif.so.x), quando você tenta compilá-lo, falha quando procura o cabeçalho para incluir no make. Uma solução é simplesmente copiá-lo do diretório de código-fonte do libgif e incluí-lo no diiretóroi local do sistema. (/usr/local/include/ na maioria dos sistemas).

Você também precisa usar o GNU make (gmake) para compilar o Window Maker.

2.16 Como corrijo um erro do tipo "wrlib: could not allocate shared memory segment: invalid argument"?

Isso diz respeito a um problema de memória compartilhada no Solaris. Usualmente você não vê, mas é visível se o X for iniciado a partir da linha de comando (ou em modo de segurança). Em qualquer caso, na saída de erro você verá uma mensagem como esta:

"wrlib: could not allocate shared memory segment: invalid argument"

Isso é gerado pelo wrlib se o Window Maker for compilado com uso compartilhado de memória (como é compilado de fábrica). A explicação é que o Solaris por padrão vem com tamanho máximo de 1M por segmento de memória compartilhada. O que ocorre é que se você tem um background realmente legal mesmo, ele usualmente será maior que o 1M de memória compartilhada. Para ver a relação entre seu padrão e a configuração IPC veja a saída do comando "sysdef" (procure por IPC Shared Memory). Você verá o tamanho máximo alocável de segmento de memória compartilhada. Se for inferior a 5M você deve incrementá-lo adicionando a seguinte linha ao seu arquivo /etc/system:

set  shmsys:shminfo_shmmax=20971520 

 

• Confira se já não tem esse valor definido. Se já tiver, simplesmente amplie o valor. No caso de você ter um valor maior, mantenha o que já tinha, porque você não tem problemas com isso.
• O valor permite um tamanho máximo de segmento de 20M, que realmente deve bastar. Se não, tente usar uma imagem de background menor!
• Confira se escreveu a linha exatamente como mostrada, de outro modo o kernel pode reclamar que não achou um nome de módulo e não mudará variável alguma!
• Assegure-se de que não removeu outra linha ou modificou sem querer, pois coisas más podem acontecer durante a inicialização se você fizer isso.
  

Depois de adicionar isto ao seu /etc/system, você precisa reiniciar para que o novo limite tenha efeito. Também, você pode querer checar o novo limite para garantir que ele funciona.

Agradecimentos a Bogdan Iamandei por esta resposta.

2.17 Como faço para adicionar o Window Maker na tela do Solaris dtlogin?

Os dois arquivos que dterminam gerenciadores de janelas alternativos são:

	/usr/dt/config/C/Xresources.d/Xresources.*
	/usr/dt/config/Xsession.*

Se você olhar ali, encontrará, respectivamente, Xresources.ow e Xsession.ow. Tudo o que precisa é configurar dois arquivos similares a esses para o Window Maker (ou qualquer outro gerenciador de janelas desejado), chamando-os de Xresources.wm e Xsession.wm (ou com a extensão que você preferir).

Aqui está uma configuração de exemplo:

	#
	**************************************************************************
	#
	# Window Maker config file
        # Mike Bland <mbland@cmu.edu>
     	#
	# /usr/dt/config/C/Xresources.d/Xresources.wm
	#
	# used by dtlogin
	#
	#
	**************************************************************************

	Dtlogin*altDtsIncrement:        True

	Dtlogin*altDtName:      Window Maker
	Dtlogin*altDtKey:       /usr/local/bin/wmaker
	Dtlogin*altDtStart:     /usr/dt/config/Xsession.wm
	#Dtlogin*altDtLogo:     /usr/local/share/logos/WM_logo.xpm

	# Once I get a logo ready, I'll add it to the dtlogin screen by
	uncommenting
	# the last line.

E este script de exemplo:

	#!/bin/ksh
	#
	**************************************************************************
	#
	# Window Maker startup script
        # Mike Bland <mbland@cmu.edu>
	# /usr/dt/config/Xsession.wm
	#
	# used by dtlogin
	#
	#
	**************************************************************************

	. /usr/local/etc/.profile       # Sources the file containing necessary
	                                # environment variables (especially
	                                # LD_LIBRARY_PATH=/usr/local/lib:...);
        	                        # make sure it's executable.

	WINDOW_MANAGER=/usr/local/bin/wmaker

	export WINDOW_MANAGER

	/usr/local/bin/wmaker

2.18 O que aconteceu com a libPropList?

A dependência da libPropList foi removida na versão 0.70.0 do Window Maker e substituída pelo código mais claro e robusto contido no toolkit WINGs. Esse novo código mantém compatibilidade com a proplist existente, de modo que não há mudanças visíveis para usuários, e os arquivos existentes funcionarão da mesma forma que antes. Para desenvolvedores, há um cabeçalho proplist.compat.h que provê mapeamento entre os nomes de função antigos e novos. Veja os comentários nesse arquivo para mais instruções.