Novo Painel configurável: Gamblermanifest

[buli]

O novo painel configurável é praticamente uma realidade. Sei que vai
provocar polêmica, e vocês tal vez fiquem shockados, mas acho que vale
a pena testar:

A partir do mesmo repositório do clica-ai, instalem via apt-get um
pacote chamado gambler. Ele depende de outros dois pacotes, krx-libs e
krx-utils, que já coloquei no repositório e o apt-get deveria instalar
também sem problemas. Após instalado, vai aparecer um ícone no
desktop, ou então abra um terminal e digite "gambler". No mais, ele
funciona igual que o clica-ai.

Para ter funcionalidade plena, vocês deveriam instalar mais outros
pacotes, por exemplo, krm-firewall e kservices, e alguns outros
talvez.

Considerem com uma versão beta, muito beta. O painel ainda não está
acabado, mas falta apenas mais um pouco de trabalho braçal. Acho bom
não divulgar nada por enquanto.


Tambén gostaria levantar as seguintes sugestões igualmente polémicas,
mas acho que necessárias:

1. Mudar o nome do projeto para o novo painel configurável.

Temos que ter independência total com o Kurumin, de nome e também
"ideológicamente" por assim dizer. Ninguem questiona seu mérito, mas a
partir dos acontecimentos recentes o Kurumin ficou com fama de ser uma
distribuição em agonia, pelo menos nos forums de outras distros,
sendo comparado inclusive com o Kalango. Na minha opinião pessoal, não
acho que o Kurumin acabe. Tal vez Morimoto falou isso para evitar
enchação de saco com relação às atualizações pois ele realmente não
tem tempo mesmo, desde anos atrás que vem dizendo isso. Tal vez os
novos releases fiquem mas espaçados no tempo. Tal vez com o fim do
Kurumin o índice de visitas ao site do GdH caia e ai ele decida
continuar com o projeto... Enfim, muitos "tal vez", acho que ninguem
sabe ao certo o que vai acontecer, mas parece-me recomendável não
ficar atrelando nosso projeto com toda a incerteza que rodea o Kurumin
no presente momento. Aliás, até o prórpio Morimoto recomendou isso pro
Passarin.

Sugiro como novo nome do projeto o seguinte: "Gambler" - Gambas
application launcher

2. O "Gambler", ou como vocês queiram chamar, pode ser costumizado
para o Kurumin como vem sendo até agora, e esse painel poderia
continuar com o nome de Clica-ai. Porém, acho que para dar
visibilidade ao projeto principal, deveria ser citado sempre como:

"Clica-ai" - powered by Gambler

A idéia é que as pessoas, principalmente de outras distros, fiquem
ciêntes que por trás do painel do Kurumin existe um outro projeto,
mais geral e abrangente, e que essa mesma "engine" pode ser portada
para seus próprios sistemas e/ou distros.

3. Embora tenha sido bom no começo, acho que deveriamos parar de ficar
clonando o painel-kommander do Morimoto, tanto no aspecto da
apariência, como na questão da organização das seções e aplicativos.
Como já disse em uma outra oportunidade, não é apenas uma questão
estética, mas também organizativa. O estilo do novo painel pode ir
tomando forma aos poucos.

Aliás, a seleção de aplicativos através do arquivo de configuração
como tem sido feita agora, eu considero como o Estágio 1. Planejo
implementar em outros estágios a modularização do painel, com novas
seções e abas que possam ser incluidas automáticamente na interface
principal, como no KControl do KDE, por exemplo, incluindo até mini-
aplicativos desenvolvidos em Gambas pelos prórpios usuários.

4. A portabilidade dos scripts do Kurumin: É uma das coisas que está
faltando para o painel ficar completo de vez. A questão é que tem
muitos scripts, dos tipos mais variados, e cada caso particular tem
que ser analizado individualmente:

a. Muitos dos scripts são bastante simples e não fazem praticamente
nada, que não seja abrir uma janela do Xterm, ou exibir uma janela do
Xdialog e coisas parecidas. Esse tipo de scripts "pequenos e simples"
eu estou modificando e incorporando direto no painel.

b. Scripts para aplicativos particulares: são mais complicados e
requerem um certo cuidado, mas nada do outro mundo. Eu estou
modificando para eles funcionar stand-alone, ou seja independentemente
de qualquer outra coisa no Kurumin, para que eles possam ser portados
para outras distros. Além disso, cada vez que algum está pronto já vou
debianizando para que possa ser disponibilizado em um pacote deb.
Esses aplicativos vão entrar como pacotes dependendentes do painel.
Exemplos:

* krm-firewall: Uma adaptação do kurumin-firewall, mais aprimorada.

* kservices e kupdatercd: também são adaptações de scripts do
kurumin, mas com uma interface gráfica, bem diferente do kommander,
mas bem integrada no KDE.

* knetcard: Idem. É um aplicativo para a configuração da rede, que
serve tanto para cabeada como wireless (descobri que a parte de rede
wireless tem alguns bugs, mas nada sério).

c. Grandes grupos temáticos de aplicativos. É de longe o mais dificil
de modificar e organizar. Não é apenas uma questão de trabalho braçal,
mas tem que ter conhecimentos do que cada aplicativo faz e como
funciona. O exemplo paradigmático é o grupo de Servidores (ftp,
apache, dns, dhcp, etc, etc.). Tem muita coisa ai, que estou deixando
para o final e ainda não sei em que vai dar.

[Passarin Jr.]

Muito bom buli! Mas não se esqueça de documentar...não adianta
desevolver algo realmente bom, mas que ninguém conseguirá utilizar.
Lembre-se de que o sucesso do Kurumin deve-se em grande à sua
facilidade de uso e facilidade na hora de encontrar bugs e corrigí-los
ou adaptá-los.
Eu estou trabalhando em alguns "mini-aplicativos" usando o Gambas2,
como o mini-aplicativo do Samba e do NFS (este último tá me dando
algum trabalho).
Estou com a galera que pretende dar continuidade ao Kurumin e por
isso defendo as 2 versões do Painel: Uma nos moldes que está sendo
feito agora e outro como vc tá sugerindo.
Também não tenho nada contra o nome sugerido e estou aí pra ajudar no
que for preciso para sucesso do projeto Glamber.
Posso recrutar uma galera pra fazer as adptações dos scritps do
Kurumin, mas vc tem que dizer exatamente como quer seja o novo padrão
destes scripts...
Abraços!

[buli]

Gostaria salientar que o que eu proponho é:

1. Apenas um único projeto, a saber, o Gambler (ou o nome que vocês
queiram), que seja um painel genérico para ser usado, em princípio, em
qualquer distro linux. Forks são sempre indesejáveis e dão um grande
trabalho depois.

2. Uma costumização do Gambler para o Kurumin, que pode ter o nome de
Clica-Ai (powered by Gambler). A engine seria exatamente a mesma. A
diferência ficaria por conta da logomarca, ícones e alguns textos.

3. Seria bom no mexer no código do painel principal até eu não
apresentar uma versão operativa do novo painel, o que tal vez aconteça
a semana que vem. Porém, o trabalho sobre mini-aplicativos
independentes pode continuar, como vc. está fazendo. Uma coisa simples
que acho que está faltando é um mini-aplicativo para Reboot igual ao
que já existe para Desligar o computador.

4. Com relação aos scripts, eu estou criando um conjunto de
bibliotecas e utilitários básicos. Estou fazendo isso para acabar com
aqueles "Xdialog" e "sudo-verificar" da vida. Como já disse antes, vou
debianizar e distribuir GPL para que possam ser instalados como
dependências do painel.

O que vai dar mas trabalho, como você já percebeu, é aquela parte de
servidores (nfs, ftp, apache, etc. etc).

Como já disse antes, cada caso tem que ser analizado individualmente,
sendo portanto dificil estabelecer um padrão genérico, mas seria
desejável o seguinte:

a. Que os scripts usem comandos básicos presentes em qualquer distro
linux. Se for usado algum comando especial, que seja documentado, para
poder incluir depois como dependência no pacote.

c. Que rode stand-alone. Ou seja, que funcione mas ou menos de maneira
independente dos outros scripts do Kurumin. Por exemplo, o famoso
"sudo-verificar" pode ser evitado incluindo apenas umas poucas linhas
no script que façam o mesmo serviço, mas sem Xdialog ou Kdialog.

b. Que seja planejado para rodar na linha de comando, sem interface
gráfica. Ou seja, em lugar de aparecer um Xdialog perguntando "escolha
o HD", por exemplo, o script deveria suportar alguma opção do tipo --
hard-disk=hda, justamente para evitar esse tipo de coisas. A interface
gráfica pode existir mas deve ser optativa. Aliás, eu recomendo tirar
de vez todos os Xdialog, e colocar no *no máximo* o Kdialog, mas acho
melhor evitar também.

Motivo: a idéia é que nosso painel rode em qualquer ambiente, tanto
KDE quanto Gnome, ou qualquer outro.

[buli]

Um pouco sobre o novo painel
======================

Em primeiro lugar, favor esqueçam e desinstalem aquela versão de
amostra que mandei por e-mail.

A configurabilidade de aplicativos dentro do novo painel segue agora
os padrões do sistema:

Existe um arquivo de configuração global:

/etc/gambler/gambler.conf

e um otro arquivo de configuração para uso pessonal do usuário:

~/.gambler/gamblerrc.

Quando você roda o comando gambler pela primeira vez ele copia o
arquivo global para o arquivo pessoal (na verdade ele verifica sempre
se arquivo pessoal existe e caso contrário copia o global).

Além de certas variáveis cujo uso vou comentar em outros post, o
arquivo de configuração contem linhas da forma

NomeDoButton=comando [opcoes]

Para fazer um teste, por exemplo abra o gambler na seção "Ferramentas
do sistema > Sudo". Se voce colocar o cursor do mouse encima de
qualquer botão, vai aparecer um nome dentro de um retángulo amarelo.
Esse é o NomeDoButton que aparece no arquivo de configuração. Então,
se você quiser trocar de aplicativo, basta procurar essa linha no
arquivo de configuração e trocar o comando. Por exemplo, perto do
final do arquivo ~/.gambler/gamblerrc
tem a seguinte linha:

BtnVisudoCheck=/usr/share/gambler/scripts/gambler.misc visudo-c

Apenas para testar, comente ela e coloque:

#BtnVisudoCheck=/usr/share/gambler/scripts/gambler.misc visudo-c
BtnVisudoCheck=kcontrol

Fazendo isso, ao apertar o botão "Checar Sintaxe" no painel vai ser
aberto o KControl. E o mesmo vale para todos os outros botões e
aplicativos.

[Passarin Jr.]

"Que seja planejado para rodar na linha de comando, sem interface
gráfica. Ou seja, em lugar de aparecer um Xdialog perguntando
"escolha
o HD", por exemplo, o script deveria suportar alguma opção do tipo --
hard-disk=hda, justamente para evitar esse tipo de coisas. A
interface
gráfica pode existir mas deve ser optativa. Aliás, eu recomendo tirar
de vez todos os Xdialog, e colocar no *no máximo* o Kdialog, mas acho
melhor evitar também."

Buli neste caso acho melhor você fazer um script-exemplo, com o novo
padrão pra que eu comece a recrutar os "scripteiros". Também coloque o
nome dos scripts que você ainda não modificou pra eu passar pra eles.

nota: em relação à interface gráfica, não acho que seja uma boa
colacar os labels que definem cada seção no painel principal em
inglês. Estamos no Brasil (pelo eu estou) e gostaria que o painel
fosse 100% (na medida do possível) em português-br. No gambas existe a
possibidade de internacionalização, quando o projeto estiver mais
maduro podemos recrutar tradutores..

off topic: o Riceman anda meio sumido....gostaria de saber o que ele
acha disso tudo...

> ...
>
> mais »

[buli]

Tem várias questões:

1. Novo painel:

Tem uma nova versão que eu chamei de 1.0.50 que é o número que
consta no arquivo .project do gambas e eu decidi adota-lo sempre que
houver alguma alteração nos fontes, e portanto no executável.

Disculpem todas as mudanças, mas... se vocês instalaram o antigo
gambler, então desinstalem e também apagem o arquivo ~/.gambler/
gamblerrc

Agora o painel é fornecido em dois pacotes deb: o gambler-common e o
gambler-bin. O primeiro pacote contem os scripts e o segundo o binário
e os ícones. Existem também um terceiro pacote deb, o gambler-src,
contendo o código fonte, mas melhor não mexer com isso por enquanto.

As dependências continuam as mesmas que o gambler anterior, ou seja,
instalando:

getuser
krx-libs
krx-utils
gambler-common
gambler-bin

vocês têm um painel minimamente funcional. Lembro que trata-se do
gambler "genérico" por isso tem muitas mudanças na interface gráfica.

A minha idéia é que quando for feita a personalização para o Kurumin,
deverá ser mudado apenas o executável no pacote gambler-bin. Por isso
achei prático dividir o painel em dois pacotes deb.


2. Scripts do kurumin. O novo painel assume que vc. deve instalar
também alguns scripts do kurumin modificados. O que eu modifiquei já
coloquei em deb para complementar o painel. Aqui tem um breve
relatório:

* knetcard: script alternativo para configuração de rede, feito com
Kaptain. A parte da rede wireless ainda não está 100% mas espero
corrigir em breve.

* krm-firewall: o firewall do kurumin. Achei que ficou bom, sugiro
testar.

* krm-modem: uma coletánea dos scripts para configurar modems no
kurumin. Também achei que ficou bom, mas como não acesso via modem não
tenho como testar.

* aptizer-utils: basicamente um wrapper para o apt-key.

* debeasy, kfpg, swapt: coloquei mas para meu uso pessoal :-) e não
sei se será de interesse de tudo mundo.

* krx-utils: contem o sudo-enable e sudo-disable para a aba "Sistema >
Sudo"

* kservices: uma outra interface em Kaptain para o gerenciamento do
serviços.

* cpufreak: também em Kaptain para o gerenciamento da frequencia do
processador, para substituir aquele ajustar-frequencia.

* gruby-lite: ferramentas de recuperação do GRUB. Isso é novo, não tem
no kurumin.


3. Eu também preciso ter algum feedback, positivo ou negativo, sobre o
rumo do projeto.

Com relação aos títulos, coloquei alguns em inglês porque, por
exemplo, o nome CUPS deriva de "Common Unix Printing System", e assim
com os demais, mas isso pode ser mudado sem problema.


4. Tarefas para voluntários:

* O pacote krm-modem resolve apenas uma parte do problema, aliás a
parte mais fácil. Para ficar completo, alguem deveria coletar todos os
módulos e firmware para modems incluidos no kurumin. Isso vai dar
muito trabalho. Além disso, tem que ser alguem que tenha no mínimo o
livro "Linux: Ferramentas técnicas" do MMT, pois aí tem bastante
informação.

* Testar todos os recursos do painel. Caso vocês acharem satisfatório,
o novo painel pode ser divulgado para beta-testers. Aliás, o fato de
ter um nome diferente ajuda, pois vcs. podem dizer que trata-se de um
outro projeto, para não comprometer o nome do Clica-Ai se o novo
painel não resultar do gosto dos usuários.

Bem, é isso por enquanto. Abraços, e bom carnaval!

> ...
>
> mais informações »

[Aline]

Olá Pessoal...

Desculpem não estar me manifestando nos ultimos dias... ando correndo um pouco.... Fim de semana lerei os emails e responderei...

Aline

Em 01/02/08, buli <troe...@gmail.com> escreveu:

[Passarin Jr.]

Não tá intalando via apt-get. diz que não achou o pacote.

buli escreveu:

> O novo painel configur�vel � praticamente uma realidade. Sei que vai
> provocar pol�mica, e voc�s tal vez fiquem shockados, mas acho que vale
> a pena testar:
>
> A partir do mesmo reposit�rio do clica-ai, instalem via apt-get um

> pacote chamado gambler. Ele depende de outros dois pacotes, krx-libs e

> krx-utils, que j� coloquei no reposit�rio e o apt-get deveria instalar
> tamb�m sem problemas. Ap�s instalado, vai aparecer um �cone no
> desktop, ou ent�o abra um terminal e digite "gambler". No mais, ele

> funciona igual que o clica-ai.
>

> Para ter funcionalidade plena, voc�s deveriam instalar mais outros

> pacotes, por exemplo, krm-firewall e kservices, e alguns outros
> talvez.
>

> Considerem com uma vers�o beta, muito beta. O painel ainda n�o est�
> acabado, mas falta apenas mais um pouco de trabalho bra�al. Acho bom
> n�o divulgar nada por enquanto.
>
>
> Tamb�n gostaria levantar as seguintes sugest�es igualmente pol�micas,
> mas acho que necess�rias:
>
> 1. Mudar o nome do projeto para o novo painel configur�vel.
>
> Temos que ter independ�ncia total com o Kurumin, de nome e tamb�m
> "ideol�gicamente" por assim dizer. Ninguem questiona seu m�rito, mas a

> partir dos acontecimentos recentes o Kurumin ficou com fama de ser uma

> distribui��o em agonia, pelo menos nos forums de outras distros,
> sendo comparado inclusive com o Kalango. Na minha opini�o pessoal, n�o

> acho que o Kurumin acabe. Tal vez Morimoto falou isso para evitar

> encha��o de saco com rela��o �s atualiza��es pois ele realmente n�o
> tem tempo mesmo, desde anos atr�s que vem dizendo isso. Tal vez os
> novos releases fiquem mas espa�ados no tempo. Tal vez com o fim do
> Kurumin o �ndice de visitas ao site do GdH caia e ai ele decida

> continuar com o projeto... Enfim, muitos "tal vez", acho que ninguem

> sabe ao certo o que vai acontecer, mas parece-me recomend�vel n�o

> ficar atrelando nosso projeto com toda a incerteza que rodea o Kurumin

> no presente momento. Ali�s, at� o pr�rpio Morimoto recomendou isso pro

> Passarin.
>
> Sugiro como novo nome do projeto o seguinte: "Gambler" - Gambas
> application launcher
>

> 2. O "Gambler", ou como voc�s queiram chamar, pode ser costumizado
> para o Kurumin como vem sendo at� agora, e esse painel poderia
> continuar com o nome de Clica-ai. Por�m, acho que para dar

> visibilidade ao projeto principal, deveria ser citado sempre como:
>
> "Clica-ai" - powered by Gambler
>

> A id�ia � que as pessoas, principalmente de outras distros, fiquem
> ci�ntes que por tr�s do painel do Kurumin existe um outro projeto,

> mais geral e abrangente, e que essa mesma "engine" pode ser portada

> para seus pr�prios sistemas e/ou distros.
>
> 3. Embora tenha sido bom no come�o, acho que deveriamos parar de ficar

> clonando o painel-kommander do Morimoto, tanto no aspecto da

> apari�ncia, como na quest�o da organiza��o das se��es e aplicativos.
> Como j� disse em uma outra oportunidade, n�o � apenas uma quest�o
> est�tica, mas tamb�m organizativa. O estilo do novo painel pode ir
> tomando forma aos poucos.
>
> Ali�s, a sele��o de aplicativos atrav�s do arquivo de configura��o
> como tem sido feita agora, eu considero como o Est�gio 1. Planejo
> implementar em outros est�gios a modulariza��o do painel, com novas
> se��es e abas que possam ser incluidas autom�ticamente na interface
> principal, como no KControl do KDE, por exemplo, incluindo at� mini-
> aplicativos desenvolvidos em Gambas pelos pr�rpios usu�rios.
>
> 4. A portabilidade dos scripts do Kurumin: � uma das coisas que est�
> faltando para o painel ficar completo de vez. A quest�o � que tem

> muitos scripts, dos tipos mais variados, e cada caso particular tem
> que ser analizado individualmente:
>

> a. Muitos dos scripts s�o bastante simples e n�o fazem praticamente
> nada, que n�o seja abrir uma janela do Xterm, ou exibir uma janela do

> Xdialog e coisas parecidas. Esse tipo de scripts "pequenos e simples"
> eu estou modificando e incorporando direto no painel.
>

> b. Scripts para aplicativos particulares: s�o mais complicados e

> requerem um certo cuidado, mas nada do outro mundo. Eu estou
> modificando para eles funcionar stand-alone, ou seja independentemente
> de qualquer outra coisa no Kurumin, para que eles possam ser portados

> para outras distros. Al�m disso, cada vez que algum est� pronto j� vou

> debianizando para que possa ser disponibilizado em um pacote deb.

> Esses aplicativos v�o entrar como pacotes dependendentes do painel.
> Exemplos:
>
> * krm-firewall: Uma adapta��o do kurumin-firewall, mais aprimorada.
>
> * kservices e kupdatercd: tamb�m s�o adapta��es de scripts do
> kurumin, mas com uma interface gr�fica, bem diferente do kommander,

> mas bem integrada no KDE.
>

> * knetcard: Idem. � um aplicativo para a configura��o da rede, que

> serve tanto para cabeada como wireless (descobri que a parte de rede

> wireless tem alguns bugs, mas nada s�rio).
>
> c. Grandes grupos tem�ticos de aplicativos. � de longe o mais dificil
> de modificar e organizar. N�o � apenas uma quest�o de trabalho bra�al,

> mas tem que ter conhecimentos do que cada aplicativo faz e como

> funciona. O exemplo paradigm�tico � o grupo de Servidores (ftp,

> apache, dns, dhcp, etc, etc.). Tem muita coisa ai, que estou deixando

> para o final e ainda n�o sei em que vai dar.

[buli]

O problema acontece com algum pacote em particular? Acabei testar
desinstalando o gambler-bin e common e reinstalando outra vez pelo apt-
get e deu certo. Qual é mensagem de erro?

======================================================================================

kurumin:/home/kurumin> sudo dpkg -r gambler-bin
(Reading database ... 103359 files and directories currently
installed.)
Removing gambler-bin ...

kurumin:/home/kurumin> sudo dpkg -r gambler-common
(Reading database ... 103348 files and directories currently
installed.)
Removing gambler-common ...
ls: /usr/share/gambler/scripts: No such file or directory

kurumin:/home/kurumin> sudo apt-get -o Dir::Etc::SourceList=/home/
kurumin/Desktop/sources.list.d/krx-deb install gambler-bin 2>/dev/null
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
gambler-common
Suggested packages:
aumix-gtk kbear kasablanca ksystemlog ksymoops
Recommended packages:
cpufreak krm-modem
The following NEW packages will be installed:
gambler-bin gambler-common
0 upgraded, 2 newly installed, 0 to remove and 97 not upgraded.
Need to get 0B/2200kB of archives.
After unpacking 2654kB of additional disk space will be used.
Do you want to continue [Y/n]?
WARNING: The following packages cannot be authenticated!
gambler-common gambler-bin
Install these packages without verification [y/N]? y
Selecting previously deselected package gambler-common.
(Reading database ... 103342 files and directories currently
installed.)
Unpacking gambler-common (from .../gambler-common_1.0.50_i386.deb) ...
Selecting previously deselected package gambler-bin.
Unpacking gambler-bin (from .../gambler-bin_1.0.50_i386.deb) ...
Setting up gambler-common (1.0.50) ...

Setting up gambler-bin (1.0.50) ...

[buli]

Acho que vc. está tentando instalar o gambler que é um pacote obsoleto
(veja os post anteriores). Agora o painel é fornecido pelo pacote
gambler-bin e suas dependências.

Para baixar manualmente pode usar o seguinte:

wget http://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/getuser_0.1_i386.deb
wget http://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-libs_0.1_i386.deb
wget http://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-utils_1.0.0_i386.deb
wget http://www.uspleste.usp.br/auil/kurumix/pool/main/g/gambler/gambler-common_1.0.50_i386.deb
wget http://www.uspleste.usp.br/auil/kurumix/pool/main/g/gambler/gambler-bin_1.0.50_i386.deb

e depois instalar com o dpkg -i na mesma ordem que consta acima.
Também testei dessa maneira e todos os pacotes baixaram sem problema.

[buli]

Esqueci dizer que tem a versão 1.0.53 que é a mais recente, mas como
não deu tempo de colocar no repositório, anexei os debs em um archive
ai abaixo, na parte "Ficheiros".

On 5 Fev, 16:05, buli <troes...@gmail.com> wrote:
> Acho que vc. está tentando instalar o gambler que é um pacote obsoleto
> (veja os post anteriores). Agora o painel é fornecido pelo pacote
> gambler-bin e suas dependências.
>
> Para baixar manualmente pode usar o seguinte:
>

> wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/getuser_...
> wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-libs...
> wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-util...
> wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/g/gambler/gambler-c...
> wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/g/gambler/gambler-b...

[Passarin Jr.]

olha os erros aí:

Os pacotes a seguir têm dependências desencontradas:
gambler-bin: Depende: krx-utils mas não vai ser instalado
Depende: gambas-gb-qt-kde mas não vai ser instalado
Depende: gambas-gb-qt-kde-html mas não vai ser
instalado
E: Dependências desencontradas. Tente `apt-get -f install' sem nenhum
pacote (ou especifique uma solução).
kurumin@kurumin:~$ sudo apt-get -f install
Lendo lista de pacotes... Pronto
Construindo árvore de dependências... Pronto
Corrigindo dependências... Pronto
Os pacotes extra a seguir serão instalados:
gambas-gb-qt-kde gambas-gb-qt-kde-html krx-utils
Pacotes recomendados:
krx-icon-theme
Os NOVOS pacotes a seguir serão instalados:
gambas-gb-qt-kde gambas-gb-qt-kde-html krx-utils
0 pacotes atualizados, 3 pacotes novos instalados, 0 a serem removidos
e 312 não atualizados.
1 pacotes não totalmente instalados ou removidos.
É preciso fazer o download de 22,6kB/71,2kB de arquivos.
Depois de desempacotar, 247kB adicionais de espaço em disco serão
usados.
Quer continuar [S/n]? s
AVISO: Os pacotes a seguir não podem ser autenticados!
krx-utils
Instalar estes pacotes sem verificação [s/N]? s
Obtendo:1 http://www.uspleste.usp.br buli/main krx-utils 1.0.0
[22,6kB]
Baixados 1B em 2s (0B/s)
Falha ao buscar http://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-utils_1.0.0_i386.deb
Tamanho incorreto
E: Impossível buscar alguns arquivos, talvez executar apt-get update
ou tentar com --fix-missing?
kurumin@kurumin:~$

On 5 fev, 16:20, buli <troes...@gmail.com> wrote:
> Esqueci dizer que tem a versão 1.0.53 que é a mais recente, mas como
> não deu tempo de colocar no repositório, anexei os debs em um archive
> ai abaixo, na parte "Ficheiros".
>
> On 5 Fev, 16:05, buli <troes...@gmail.com> wrote:
>
> > Acho que vc. está tentando instalar o gambler que é um pacote obsoleto
> > (veja os post anteriores). Agora o painel é fornecido pelo pacote
> > gambler-bin e suas dependências.
>
> > Para baixar manualmente pode usar o seguinte:
>
> > wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/getuser_...
> > wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-libs...
> > wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-util...
> > wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/g/gambler/gambler-c...
> > wgethttp://www.uspleste.usp.br/auil/kurumix/pool/main/g/gambler/gambler-b...
>
> > e depois instalar com o dpkg -i na mesma ordem que consta acima.
> > Também testei dessa maneira e todos os pacotes baixaram sem problema.
>
> > On 5 Fev, 15:42, buli <troes...@gmail.com> wrote:
>
> > > O problema acontece com algum pacote em particular? Acabei testar
> > > desinstalando o gambler-bin e common e reinstalando outra vez pelo apt-
> > > get e deu certo. Qual é mensagem de erro?
>

> > > ===========================================================================­===========

[buli]

Ok. O pacote que está dando problema é o krx-utils. Favor, pegue ele
via wget do endereço que dexei acima, ou então melhor ainda, pegue
diretamente do archive que postei, pois é uma versão mas recente (a
pesar do número) e instale manualmente com o comando:

sudo dpkg -i krx-utils_1.0.0_i386.deb

O problema não é com o pacote, mas com o repositório, portanto
deveria instalar bem. Vou corrigir isso posteriormente, somente afeta
o gambler, e não o clica-ai.

> Obtendo:1http://www.uspleste.usp.brbuli/main krx-utils 1.0.0

> [22,6kB]
> Baixados 1B em 2s (0B/s)

> Falha ao buscarhttp://www.uspleste.usp.br/auil/kurumix/pool/main/k/krm-base/krx-util...

[Passarin Jr.]

Tudo Ok! Desinstalei tudo e baixei o pacote Tar.gz que você postou
aqui e instalei tudo (dpkg -i * .deb). Agora tá beleza.
Algumas considerações:
Da forma como o Painel tá ainda precisa ser "personalizado" para o
Kurumin.
Notei que vc modificou muita coisa na interface gráfica, adicionando
várias opções e também modificou o nome de outras. Eu gostei do modo
como ficou organizado mas acho que será preciso um pequeno manual ou
índice pra que o usuário encontre com um certa rapidez e de maneira
intuitiva o que está procurando...
Outra coisa, não sei o que fazer neste projeto pra ajudar no
Desenvolvimento...poderia fazer a adptação dele para o Kurumin, mas em
alguns casos eu iria precisar do código-fonte e saber como as coisas
estão funcionando neste novo painel...sem isso fico só esperando pra
ver no que dá...
Infelizmente por esse motivo estou fazendo paralelamente uma versão
usando o Gambas2. Entenda, não estou querendo criar duas versões do
Painel, mas um dos motivos pra eu iniciar este projeto foi a chance de
aprender a programar usando o Gambas e ao mesmo tempo fazer algo que
pudesse ser útil pra outros usuários...não sei ficar parado...
Abraços!

> > Obtendo:1http://www.uspleste.usp.brbuli/mainkrx-utils 1.0.0

[Riceman]

Oi, pessoal!

Desculpem o sumiço, a coisa tá corrida no trabalho e está sobrando
pouco tempo pro lazer ;-)
Primeiro de tudo, seja bem-vinda ao grupo Aline (um pouco atrasado mas
tudo bem).

Bem, vamos começar os comentários...

Tirei um tempo agora para ler todos os posts que não tinha
acompanhado, baixei Gambler dos ficheiros deste grupo e dei uma
testada. Acho que as idéias do Buli são ótimas e adorei como ficou o
painel. Também gostei do nome sugerido.

Buli,

1)
Analisando o código fonte, percebi que você alterou apenas o
FormPrincipal baseado o Clica-ai-1.7.1. É isso mesmo? Por favor
confirme, pois caso seja verdade será possível mesclar facilmente com
um pequeno teste de portabilidade que eu fiz algum tempo atrás para os
formulários dos ícones mágicos. Criei, na época, um arquivo de
configurações parecido com o seu "gamblerrc", porém contendo apenas o
endereço dos scripts do Morimoto a ser chamado pelo Ícones Mágicos.

Existe uma grande redução no código dos formulários devido à
padronização das funções lendo as informações do arquivo. Ficou apenas
uma função para todos os botões instalar em cada formulário dos ícones
mágicos, mais a função de centralização do formulário adicionada pelo
Passarin.

As funções padronizadas estão em um módulo chamado "Scripts" que
contém 2 funções. Uma que lê as informações no arquivo e coloca em um
array. E outra que executa esta função e chama o xterm para executar o
script relativo ao botão clicado.

Alguns comentários sobre estas alterações se encontram alguns posts no
tópico "cronogramas e metas para o clica-ai" deste grupo.

Fiz um teste inserindo meu código no Gambler postado aqui no grupo.
Veja o arquivo "Gambler_1.0.54.tar.gz" contendo apenas o código fonte
alterado.

2)
Percebi que ficaram muitas funções do tipo "SHELL "`gambler -b
BtnDlinkDW650`"" que podem ser substituídas por uma só com algum
trabalho braçal, da mesma forma que fiz para os Ícones Mágicos
(definindo o Tag igual ao nome do botão, e chamndo através em uma
função em um módulo).

3)
Por favor explique o que são as pastas "FormPrincipal.class.d" e
"FormPrincipal.form.d". Percebi que são trechos do código do
FormPrincipal a e sua definição de componentes gráficos como nos
arquivos ".class" e ".form" criados pelo gambas. Apenas para nosso
entendimento.

4)
O procedimento que realizei para mesclar nossos projetos foi:

4.1 Substituir os arquivos .class e .form dos formulários dos ícones
mágicos pelos do projeto Clica-ai-1.7.2 (meu teste)

4.2 Copiei o arquivo "Scripts.module" para a raiz do projeto Gambler

4.3 Copiei o conteúdo do arquivo "clica-ai.conf" (na pasta do arquivo
postado) para dentro do arquivo "gamblerrc" e alterei a constante que
o endereço do arquivo de configurações no "Módulo Script"

Funcionou perfeitamente! Porém o Menu agora está operando de 2 modos
distintos baseado no mesmo arquivo de configurações.
A sua parte está rodando baseado nos comandos "gambler -b" e a minha
baseada no "Script.Call" definido no meu módulo. Sugiro padronizar.
Por favor opine sobre como considera ser a melhor forma.

5)
Percebi que você renomeou alguns arquivos dos formulários dos Ícones
Mágicos. Espero que tenha sido somente os nomes, pois eu os substituí
pelos meus, porém deixei os mesmos nomes para os quais você alterou.

6)
Por curiosidade de aprender, como foi que você fez o executável do
gambas trabalhar com argumentos na interface de texto, como o "gambler
-b <Nome_do_Botao>" por exemplo? Onde você programou estas funções?


Desculpem, foi um grande texto, mas também foi muito tempo que fiquei
fora, e por conseqüências ficaram muitas coisas por comentar.

Um abraço a todos!

Riceman

[buli]

Com relação às questões postadas pelo Riceman:


1.e 5. A minha base foi o 1.7.1 mesmo. Dai eu gerei o 1.7.2 e depois
passou para o gambler 1.0.53.

IMPORTANTE: eu somente modifiquei os arquivos FormPrincipal.form e
FormPrincipal.class. Todos os outros Form eu não mexi nada. Portanto,
qualquer modificação feita nos Form dos icones mágicos, ou outros,
pode ser portada diretamente. Se houve alguma alteração no nome dos
arquivos foi apenas isso, o conteúdo ficou igual, portanto acho que
tudo ficou certo.


2. e 6. Como vcs. perceberam, o FormPrincipal.class ficou quase que
totalmente com apenas um único tipo de função, aquelas do tipo:

SHELL "`gambler -b BtnDlinkDW650`"

Como Riceman já observou, o código do .class poderia ser reduzido por
causa disso. Mas eu não conhecia aquele esquema do Script.call que ele
tinha bolado. Nós temos que padronizar, certamente, e sugiro que
adotemos o esquema com a melhor performance em tempo de execução.
Probablemente esse esquema seja o do Script.call, pois é feito dentro
do prórpio gambas, por assim dizer.

Vou esclarecer como funciona o esquema do "gambler -b", em parte para
responder as questões do Riceman, em parte para vcs. saberem como
funciona:

O comando "gambler" é aquele shell-script que eu tinha colocado na
pasta /usr/bin e que servia para executar o binário do gambas,
independentemente do nome do painel. Eu acresentei o opção -b, de
button ou botão, que faz o seguinte: quando você roda, por exemplo, o
comando:

gambler -b BtnDlinkDW650

ele procura no arquivo ~/.gambler/gamblerrc alguma linha que começe
com o nome fornecido como argumento na linha de comando, que no caso
do exemplo acima seria BtnDlinkW650. Se ele achar uma tal linha, então
ele tenta ler o que estiver colocado à direita do sinal = e esse ai
deve ser o nome do comando a ser executado. Se ele não encontrar a
linha ou não conseguir ler o nome do comando, então ele tenta fazer a
mesma coisa com o arquivo de configuração global /etc/gambler/
gambler.conf. Se não achar nada ai também não, então desiste e nada é
feito.

Como ele procura a linha que começe exatamente com o nome do button,
ele ignora qualquer linha em branco ou que começe com o caracter #,
por exemplo, o que permite acrescentar comentários nos arquivos de
configuração, igual que o padrão do sistema.

Antes de voltar para o .class é necessário mais um esclarecimento
sobre a Bash, ou seja própria shell usada no Linux. A bash tem um
recurso muito útil que consiste no seguinte: quando você coloca algum
comando entre aspas simples invertidas ela executa primeiro o comando,
substiui o resultado na shell e depois continua com a execução normal.
Vou dar o seguinte exemplo simples: suponha que você quer dar uma
olhada em algum script diretamente no terminal, usando o "cat" ou o
"more", mas você não lembra em qual pasta estava o script. Para
localizar executáveis no sistema você pode usar o comando "which", que
retorna o path do executável, se tal executável existir, por exemplo:

$ which gambler
/usr/bin/gambler

Agora, para visualizar o conteúdo do script vc. deveria usar o
comando:

$ more /usr/bin/gambler

Porém, alternativamente, vc. pode "matar dois coelhos de uma cajadada
só" usando aquele recurso das aspas simples invertidas, e fazer o
seguinte:

$ more `which gambler`

Nesse caso, a bash vai executar primeiro o comando que estiver contido
entre as aspas, which gambler, vai substituir o resultado, /usr/bin/
gambler, e depois disso vai executar a linha de comando original, ou
seja ficaria

$ more /usr/bin/gambler

que era o comando que deveria ser executado no caso do exemplo.

Agora, voltando para o arquivo .class, vocês vão perceber que todos o
comandos gambler -b estão entre aspas simples invertidas. Portanto a
shell vai executar primeiro o comando gambler -b e vai substituir o
resultado no seu lugar. Esse resultado, pela sua vez é o nome do
comando a ser executado pelo painel, que vai ser repassado para o
SHELL que fica no começo da linha:

SHELL "`gambler -b BtnDlinkDW650`"

SHELL " <substitui com o nome do comando>"

e depois executa.

É assim que funciona. Exceto pelo fato de acrescentar a opção -b no
script gambler, eu não teve que programar essas funções em lugar
nenhum, a própria shell é que faz todo o trabalho para nós!


4. Acho que o esquema do script.call é mais eficiente em tempo de
execução. Somente tenho a seguinte dúvida: para mudar a configuração
de algum aplicativo parece-me que deveria ser modificado o arquivo
dentro do projeto e depois o painel teria que ser *recompilado* outra
vez. Estou certo?

O esquema do "gambler -b" funciona com o binário "as is" e não
precisaria de recompilar após cada alteração.

Eu vou estudar o esquema script.call e depois vemos como e qual
implementar.


3. As pastas FormPrincipal.*.d contém de fato trechos dos Form do
projeto. Elas não afetam em nada o projeto, mas apenas refletem a
maneira como eu trabalhaba nele.

A pasta FormPrincipal.form.d não contém quase nada, mas apenas um
modelo de aba, que eu usava como "template" cada vez que queria
acrescentar uma nova aba no projeto principal.

Já a pasta FormPrincipal.class.d contém contem o arquivo
FormPrincipal.class quebrado em diferentes partes. O arquivo 00Main
contém o código com as funções comunes a todo o projeto como assim
também aquele do painel principal (aquele que diz "Bem-vindo..."). Os
outros arquivos vão do 01... ao 06... e correspondem exatamente a cada
um dos MainToolButtons do painel, que são 6 ao total. Ou seja, o
código button "Ferramentas do sistema" está contido no arquivo
06System e não se mistura com nenhum outro arquivo, e mesma coisa
acontece com os outros buttons e arquivos.

Como eu trabalhava sempre sobre algum button de cada vez, para mim era
mais simples entrar no arquivo correspondentes e fazer as alterações
ai e depois juntar todos os pedaços dentro do projeto principal.

Aliás, eu bolei um script chamado mkformclass que junta todos os
pedaços na ordem e gera o arquivo FormPrincipal.class. Esse script é
fornecido junto com o pacote gambler-src, sendo instalado na pasta /
usr/bin.

Eu não apaguei as pastas e conservei o script porque tenho planes para
eles no futuro. Mas por enquanto não afetam o projeto. Quem quiser
pode ficar brincando com o script, mas NÃO recomendo experimentar sem
ter feito um backup do projeto antes! O funcionamento básico é o
seguinte:

$ cd <pasta onde consta o projeto>
$ mkformclass

Sem o comando "cd" antes não vai dar certo.

[Riceman]

Buli,

Perfeito, entendi seu raciocínio. Apenas para esclarecer sua dúvida em
relação ao trecho abaixo:

> 4. Acho que o esquema do script.call é mais eficiente em tempo de
> execução. Somente tenho a seguinte dúvida: para mudar a configuração
> de algum aplicativo parece-me que deveria ser modificado o arquivo
> dentro do projeto e depois o painel teria que ser *recompilado* outra
> vez. Estou certo?

Na realidade, não é necessário recompilar ao fazer alterações somente
dentro do aqruivo de configuração obedecendo o padrão
(<Nome_do_Botão>=<Comado>).

Se você estudar a função que lê as linhas do arquivo, via perceber que
adicionei um IF que descarta as linhas vazias e as linhas de
comentários (começando com #), de modo que funciona extamente como seu
script "-b".

Como o arquivo é lido todas as vezes que o comando "Script.Call" é
chamado, as alterações no seu conteúdo serão assumidas mesmo que o
painel esteja sendo executado, logo após o usuário salvar as
alterações no arquivo de configurações e clicar em algum botão que
chame este script.

Como, por uma feliz coincidência, sem nos falarmos criamos arquivos de
configuração com o mesmo padrão, o único trabalho necessário para
padronizar de modo a executar com o módulo Script, é definir os TAGs
de cada botão que necessita desta função igual ao seu próprio nome.
Isto porque não consegui descobrir uma maneira de ler a propriedade
"Name" dos objetos no Gambas diretamente.
Adicionalmente pode-se definir o nome do Grupo destes botões com um
mesmo valor para que possam ser chamados por uma única função no
FormPrincipal.class.
Veja as propriedades de algum botão "Instalar" nos formulários dos
Ícones Mágicos e como foi escrito o código por trás. É muito simples,
mas é um grande trabalho braçal.

Fico no aguardo de sua opinião para padronizarmos o código.

Um Abraço,

Riceman

[buli]

Riceman,

já entendi mais ou menos como funciona, mas ainda não consegui testar
o desempenho por que teve um probleminha, acho que não estou fazendo a
coisa certa.

Eu baxei o 1.0.54, compilei o binário e painel abre perfeito. Também
copiei o arquivo gamblerrc que vc. modificou (anexando o clica-ai.conf
no final) para a pasta ~/.gambler. Fora isso não fiz mais nada.

Quando tentei instalar um pacote pelos IM apareceu uma mensagem de
erro, em todos os casos que eu tentei. Sempre a mesma mensagem.

Eu postei um screenshot na parte "Ficheiros". Vc. tem idéia do que
pode ser?

[buli]

Solucionei o problema trocando no Script.module a linha

OPEN ConfAddr FOR READ AS Confs

pela seguinte nova linha:

OPEN ConfFile FOR READ AS Confs

Testei e funcionou perfeito.

Depois modifiquei outras coisas, porque achei que assim ficava mais
simples. Tambem testei e deu certo.

Não achei uma diferença de desempenho significativa entre os dois
esquemas, mas o Script.module parece-me mais elegante, além do fato de
estar integrado no gambas, por tanto se vc. concorda podemos
padronizar para esse esquema mesmo.

Isso de definir o tag igual ao nome do button para cada button eu
entendo. Os buttons nos form dos IM pertencem todos ao grupo Instalar,
não é assim? Não sei se vale a pena criar um grupo diferente para os
outros buttons.

Não sei se estou certo, mas acho que todos os buttons "configuráveis"
poderiam pertencer ao mesmo grupo, que poderia ser denominado Command,
ou Comando, não sei o que vc. acha.

Nesse caso o Instalar teria que ser trocado para Command(o), mas isso
pode ser automatizado via sed. Se vc. concordar eu posso cuidar
disso.

Então, em resumo, tem as seguintes questões:

* Usar o esquema Script.module no resto do painel.

* Definir os tags idem.

* Mudar Instalar para Command nos form dos IM.

Tem também o seguinte:

* Como já disse antes eu modifique o Script.module. Eu vou postar em
"Ficheiros" para que vc. de uma conferida.

* Além disso, fiz uma adaptação no Script.module que eu chamei de
Script.module-var. Ele tem a mesma função que o script module, mas
serve para procurar os nomes dos buttons em vários arquivos de
configuração diferentes. O que ele faz é o seguinte: pega todos os
arquivos que estiverem na pasta ~/.gambler/ e concatena todos criando
um único chamado /tmp/gambler.rc na pasta /tmp e esse arquivo de
configuração temporário é o finalmente acessado pela função do
Script.module e apagado no final. Eu postei também junto em "
Ficheiros"

Você pode achar estranho, mas estou elaborando a idéia de quebrar o
painel em "módulos". Cada módulo corresponderia a uma aba, e eles
poderiam ser tirados do painel para funcionar independentemente, como
os KCMShell do KDE.

Cada módulo seria um mini-painel independente, com arquivo de config.
próprio, por isso trabalho com a hipótese de ter vários arquivos de
config.

Fico então no aguardo de vc. me dizer como vc. acha que seria a
melhor maneira de organizar o trabalho de padronização do código para
o esquema Script.module.

[Riceman]

Buli,

> Solucionei o problema trocando no Script.module a linha
>
> OPEN ConfAddr FOR READ AS Confs
>
> pela seguinte nova linha:
>
> OPEN ConfFile FOR READ AS Confs
>
> Testei e funcionou perfeito.

É exatamente isso. Eu fiz algumas alterações nestas variáveis e devo
ter esquecido de corrigir nesta parte do código. Só não entendo como
funcionou comigo, pois eu testei cada botão em cada aba dor Ícones
Mágicos e funcionou. Mas tudo bem, era um erro e agora está corrigido.
Valeu!

Quanto às suas colocações:

> * Usar o esquema Script.module no resto do painel.

---Concordo---

> * Definir os tags idem.

---Concordo. Você falou em usar o SED. Eu não tenho muita experiência
com ele, mas talvez você possa fazer algo para automatizar isso.
Observe os arquivos ".form". Todos os objetos começam sua definição
com uma "{" e logo em seguida seu "Nome". Poderíamos tentar usar o SED
para localizar os Nomes e (agora a parte que não sei) inserir dentro
das chaves deste objeto a linha contendo Tag = "<Nome>".
Contudo se você observar nos arquivos .form vai perceber que a
propriedade Tag, quando definida, está sempre em uma mesmo local (após
"Background" e antes de "Mouse"). Não sei se esta posição precisa ser
fixa para funcionar, ou se o Tag poderia ser inserido na linha
anterior à "}" de fechamento.
Seria o caso de testar. Mas, por favor, faça uma cópia ou um backup
antes. Você sabe que o SED pode ser perigoso, visto que estará
alterando diretamente o conteúdo do arquivo.---

> * Mudar Instalar para Command nos form dos IM.

---Não há necessidade, pois os grupos são limitados ao formulário ao
qual pertencem. Apesar de eu ter utilizado o mesmo nome, a função do
grupo Instalar no formulário de Utilitários não consegue ler uma
função em outro formulário (nem no Main), por isso tive que deixar uma
cópia da função chamando Script.Call em cada formulário.

Isto significa que podemos definir o grupo "Comando" para o
FormPrincipal sem interferir nos outros.

Na minha opinição deveríamos manter "Instalar" para os Ícones Mágicos
e "Comando" para o FormPrincipal, meramente pela diferenciação. Mas
não terá nenhum impacto no desempenho ou no funcionamento do
painel.---

> Tem também o seguinte:

> * Como já disse antes eu modifiquei o Script.module. Eu vou postar em

> "Ficheiros" para que vc. de uma conferida.

---Vi que sua alteração foi bem pequena, apenas no modo de detectar a
pasta Home e o endereço do arquivo de configuração (fora a correção
acima). Por mim sem problemas---

> * Além disso, fiz uma adaptação no Script.module que eu chamei de
> Script.module-var. Ele tem a mesma função que o script module, mas
> serve para procurar os nomes dos buttons em vários arquivos de
> configuração diferentes. O que ele faz é o seguinte: pega todos os
> arquivos que estiverem na pasta ~/.gambler/ e concatena todos criando
> um único chamado /tmp/gambler.rc na pasta /tmp e esse arquivo de
> configuração temporário é o finalmente acessado pela função do
> Script.module e apagado no final. Eu postei também junto em "
> Ficheiros"

---Acho uma boa idéia, vai torná-lo ainda mais flexível. Analisei seu
código e concordo com suas alterações. Vamos manter este Módulo.---

> Você pode achar estranho, mas estou elaborando a idéia de quebrar o
> painel em "módulos". Cada módulo corresponderia a uma aba, e eles
> poderiam ser tirados do painel para funcionar independentemente, como
> os KCMShell do KDE.
> Cada módulo seria um mini-painel independente, com arquivo de config.
> próprio, por isso trabalho com a hipótese de ter vários arquivos de
> config.

---Isto é o que mencionei naquele post em que falei "Porque o Morimoto
não vai adotar nosso menu!" (flexibilidade). Concordo plenamente com
você, porém isto significa que teríamos vários executáveis do gambas,
e teríamos que fazer o Painel Principal chamar estes executáveis a
cada vez que o usuário clicasse em um botão para chamá-los. Acredito
que isso reduziria um pouco o desempenho do painel.

Mas não acho que deveríamos descartar esta idéia. Vamos seguir
discutindo sobre isso.---

Um abraço,

Riceman

[buli]

Ok! Tal vez mexa neste final de semana, e na semana próxima comunico
as novedades.

[Passarin Jr.]

não sei se vocês leram o meu post sobre passar a bola pra vocês...
buli vc tá como admin deste grupo agora. Vou estar sempre passando por
aqui mas deixo o desenvolvimento pra vocês. Estou trabalhando junto
com outros membros em um possível continuação do Kurumin e assim que
tiverem algo que possa ser testado pelos users eu posto neste fórum:
http://tuxsabe.com.br/kurumindev/index.php?sid=26f18a4203bac3e1ada0c4403f393a72
Mas acho que pra ser usado no Kurumin o gambler precisa ser
personalizado, tirando o Tux do form principal e colocando o logo do
Kurumin, mas isso eu mesmo faço posteriormente!
Abraços! e Bom trabalho!

[buli]

Finalmente consegui portar o painel para o novo esquema, mas tem ainda
várias questões em aberto. Vamos por partes:

1. Postei na parte "Ficheiros" um archive com os fontes da versão
1.0.55 que pasou a ser a mais atual.

O trabalho foi facilitado pelo fato de ter usado nomes especiais para
o botões "não-configuráveis", ou seja, aqueles cujo comportamento não
pode ser alterado via arquivo de configuração. Se não fosse por isso,
além da substituição via script, teria sido necessária a edição manual
dos form.

Portanto, sugiro continuar com essa idéia. Os padrões que eu tinha
usado foram:

BtnForm* : buttons que inciam outros forms dentro do projeto.

BtnInfo* : buttons que abrem caixas de texto dentro do prórprio
gambas, aqueles do tipo "Mais Informações".

BtnInfoUrl* : buttons do grupo UrlGuias, ou seja, são buttons que
abrem páginas url via browser.

Aliás, acho que a única coisa que faltaria para completar, seria a
configuração dos endereços URL. Eu não sei muito bem como fazer, não
sei se vc. Riceman tem alguma idéia. Mas acho que isso pode ser
acrescentado em futuras versões.

=======================================================================

Com relação ao que foi postado, Tem várias mudanças:

FormPrincipal* passou a ser FormMain*

O diretório de ícones agora é "icons" e o de imagens é "pictures".

As pastas FormMain.*.d agora contêm o painel inteiro dividido em
"módulos", onde cada módulo corresponde exatamente com uma aba do
painel. Não é para mexer, pelo momento, mas apenas um anticipo do
futuro. Vou acrescentar maiores esclarecimentos em futuros posts.

A pasta "info" contém os arquivos de configuração do painel. Para vcs.
poderem usar o painel, peguem apenas os arquivos com extensão .conf,
copiem eles para a pasta ~/.gambler/ e renomeiem da seguinte maneira:

arquivo.conf -> arquivorc

ou seja, trocando o ponto-conf por rc (de "running commands").

Acho que o painel já pode ser disponibilizado para testes. Na verdade
já está quase pronto. O único que está faltando é organizar o
empacotamento em deb e disponibilizar via apt. Isso vai me dar um
pouco de trabalho ainda, portando peço um pouco de paciência nesse
sentido.


2. Usando o gambler-1.0.55 fiz a adaptação para o kurumin, que também
postei na parte ficheiros e tem o nome clica-ai-1.0.55, mas que na
verdade poderia ser 1.8 quando lançado, isso fica a critério de vcs.

3. Além dos fontes postei os binários respectivos.

Para fins de desenvolvimento, criei uma função que verifica quais
ícones e imagens estão sendo de fato utilizados no FormMain.form e
apaga da pasta do projeto aqueles sem uso. Com isso, e tirando alguma
outras coisas desnecessárias, consegui gerar um binário de 1.8MB.
Acredito que esse tamanho esteja perto do patamar mínimo, pois somente
as imagens dos ícones mágicos, que já estão em formato compactado,
ocupam 1.4MB.

========================================================================

Questões "técnicas":

1. Consegui identificar um aspecto em que o Script.module supera a
outra abordagem, a saber: com o gambler -b é impossível usar comandos
que contém certos meta-caracteres da shell, por exemplo:

BtnCUPSStop=kdialog --msgbox "`/etc/init.d/cupsys stop 2>/dev/null`"

Esse tipo de comando é muito prático, pois permite comunicar a saida
do comando ou de erro para o usúario, com um acabamento melhor que se
fosse simplemesmente uma coisa do gênero:

BtnBtnCUPSStop=xterm -e "/etc/init.d/cupsys stop"

Como já disse, isso não é possível no "plano -b", pois no processo de
leitura e re-envio do comando para sua execução, o carater ` é
interpredado literalmente, ou seja, como sendo apenas uma aspa simples
reversa, e não como um meta-caracter cujo significado na shell é bem
diferente, desvirtuando dessa maneira o comando original, que fica
dessa maneira imprestável.

O Script.module consegue fazer isso, desde que você troque:

`/etc/init.d/cupsys stop 2>/dev/null`

por:

$(/etc/init.d/cupsys stop 2>/dev/null)

o efeito é o mesmo, com a diferença que no segundo caso o comando é
executado numa sub-shell.

O motivo disso dar certo eu não entendo muito bem, mas decidi que
valia a pena aproveitar.


2. Por outro lado, existem algumas situações que eu não consegui
adequar ao Script.module:

* Combo-boxes: O comando a ser executado depende da escolha do usuário
na combo-box, e o script.module funciona lendo o arquivo de config. Eu
não soube como fazer ele ler o resultado na combo-box.

* Comandos que contem o sinal = na linha de comando. Por exemplo:

BtnKrmFirewallSet=krm-firewall -s --action=set

Por causa disso, o plano -b ainda não foi descartado e continua sendo
usado:

* Na aba "Rede > Modem Discado" existem duas combo-box.

* Na aba "Rede > Kurumin-Firewall" existem comandos com =.

Mas tirando esses dois casos, o resto do painel usa o script.module.

Para chavear entre um modo ou outro, basta apenas incluir ou excluir o
botão no grupo Comando.

Uma outra coisa que eu tentei, foi colocar linhas repetidas com o
mesmo nome do botão para ver o que acontecia, e aparentemente o
script sempre pega a última que tiver.

========================================================================

Bem, acho que é isso por enquanto. Qualquer dúvida, favor postem.

Abraços.

On 15 Fev, 01:24, "Passarin Jr." <passa...@gmail.com> wrote:
> não sei se vocês leram o meu post sobre passar a bola pra vocês...
> buli vc tá como admin deste grupo agora. Vou estar sempre passando por
> aqui mas deixo o desenvolvimento pra vocês. Estou trabalhando junto
> com outros membros em um possível continuação do Kurumin e assim que

> tiverem algo que possa ser testado pelos users eu posto neste fórum:http://tuxsabe.com.br/kurumindev/index.php?sid=26f18a4203bac3e1ada0c4...

[buli]

Riceman,

esqueci dizer antes, mas também teve que fazer alguns pequenos ajustes
no código do Script.module.

Aparentemente, o arquivo de conf. temporário na pasta não era criado
"suficientemente rápido" e dava um erro de arquivo não-encontrado.
Outra explicação não saberia dizer.

Uma outra coisa estranha é que a função principal não conseguia apagar
o arquivo temporário no final. Somente tirando o "rm" para fora dela.
Mas ai teve que acrescentar um RETURN ConfFile para salvar o nome do
arquivo "para fora".

Eu testei após as mudanças e funcionou bem, mas é sempre bom
conferir.


Com relação a questões do outro post:

> ---Isto é o que mencionei naquele post em que falei "Porque o Morimoto
> não vai adotar nosso menu!" (flexibilidade).

O esquema que estou bolando resoveria justamente esta questão.

> Concordo plenamente com
> você, porém isto significa que teríamos vários executáveis do gambas,
> e teríamos que fazer o Painel Principal chamar estes executáveis a
> cada vez que o usuário clicasse em um botão para chamá-los. Acredito
> que isso reduziria um pouco o desempenho do painel.

Binários rodando por separado é mais ou menos o que a gente já tem,
com o panel principal que abre outros mini-paneis, como aquele do
LTSP.

O que eu estou planejando é outra coisa. Dá uma olhada no screenshot
que postei junto com os sources do gambler-1.0.55.

Ou seja, o painel continuaria funcionando com "tudo dentro", sem perda
de desempenho. Seriam as abas que seriam tiradas dele para rodar stand-
alone.

Você pode pensar que ter muitos binários é ruim em termos de espaço,
mas tirando o caso dos ícones mágicos, que tem 1.4MB apenas em
*imágens*, as abas independentes são levíssimas, com um binário apenas
entre 10KB e 30KB, segundo meus testes.

Vou comunicar quando tiver mais novidades.

[Riceman]

Buli,

Nossa trabalho em conjunto está dando resultado. Está ficando muito
bom. Vide abaixo meus comentários às suas colocações:

> Portanto, sugiro continuar com essa idéia. Os padrões que eu tinha
> usado foram:
> BtnForm* : buttons que inciam outros forms dentro do projeto.
>
> BtnInfo* : buttons que abrem caixas de texto dentro do prórprio
> gambas, aqueles do tipo "Mais Informações".
>
> BtnInfoUrl* : buttons do grupo UrlGuias, ou seja, são buttons que
> abrem páginas url via browser.

---Concordo.---

> Aliás, acho que a única coisa que faltaria para completar, seria a
> configuração dos endereços URL.

---Não é muito difícil. Na verdade o esquema é o mesmo das
configurações dos Botões. Note que no Script.Module eu estou
populacionando uma coleção dinamicamente lendo de um arquivo, e no
Url.module estou criando uma colação com a mesma estrutura porém de
forma constante.

Deixe esta comigo que eu farei a adaptação mais adiante e postarei.
Agora estou postando correções que você comentou no seu post, que
considero mais urgentes para liberarmos a nova versão.

=======================================================================

> Com relação ao que foi postado, Tem várias mudanças:
>

> A pasta "info" contém os arquivos de configuração do painel. Para vcs.
> poderem usar o painel, peguem apenas os arquivos com extensão .conf,
> copiem eles para a pasta ~/.gambler/ e renomeiem da seguinte maneira:
>
> arquivo.conf -> arquivorc

---Na realidade não há necessidade de renomear. Inclusive eu acho
melhor deixar como ".conf" para ficar visível para o usuário que é uma
configuração do painel.
Note que no código que você alterou no Script.module você junta *
(todos os arquivos independente do seu nome).

SHELL "cat $HOME/.gambler/* >" & ConfFile WAIT

É preciso arrumar no pacote de instalação para remover o gamblerrc que
havia lá e deixar somente estes novos arquivos ".conf".

Encontrei um "erro" no arquivo main.conf. Não havia novas linhas
vazias ao final do arquivo, de modo que quando o cat juntava ele com
outro, a linha do primeiro botão ficava grudada com a última linha
deste arquivo, gerando por sua vez uma linha com mais de um "=" que
resultaria em um comando bem estranho com nome de botão no meio e
tudo. O arquivo no pacote 1.0.56 já está corrigido.

Nota:
Não entendi pra quê serviam as linhas abaixo, então simplesmente
comentei. Não tive nenhum bug conforme dito no comentário.
--------------------------------------------------------------------------------------------------------------------
'Da um tempo antes de processar o arquivo temporário, para evitar um
bug.
'SHELL "sleep `grep ^SCRIPT_DELAY= $HOME/.gambler/gamblerrc|cut -d= -
f2`"
--------------------------------------------------------------------------------------------------------------------

Talvez possa ser removido para limpar o código.

> Acho que o painel já pode ser disponibilizado para testes. Na verdade
> já está quase pronto.

---Concordo. Porém poste esta versão 1.0.56 nos arquivos deste grupo.
Ela contém os melhoramentos mencionados aqui.---

> 2. Usando o gambler-1.0.55 fiz a adaptação para o kurumin, que também
> postei na parte ficheiros e tem o nome clica-ai-1.0.55, mas que na
> verdade poderia ser 1.8 quando lançado, isso fica a critério de vcs.

---Acho que deveríamos manter a numeração do Clica-Ai e liberar como
1.8. Por favor, atualize-o para ser baseado no Gambler 1.0.56 (não sei
exatamente o que você alterou)

========================================================================

> Questões "técnicas":

>
> 2. Por outro lado, existem algumas situações que eu não consegui
> adequar ao Script.module:
>
> * Combo-boxes: O comando a ser executado depende da escolha do usuário
> na combo-box, e o script.module funciona lendo o arquivo de config. Eu
> não soube como fazer ele ler o resultado na combo-box.

---No caso das ComboBoxes não tem jeito executar usando LAST e Tag,
visto que há mais de um valor que pode ser assumido. Neste caso é
preciso manter a mesma estrutura que você tinha para o "gambler -b",
porém chamando o Script.Call.
Veja no código. Eu mantive a estrutura "gambler -b" comentada, visto
que percebi que você manteve os códigos "gambler -b" independentes por
botão, para poder fazer o chaveamento entre o uso do Script.module
(adicionando o Grupo = Comando como você mencionou) e o "gambler -b".

Se vamos abrir mão totalmente do "gambler -b", podemos excluir todo
este código. Isto vai reduzir ainda mais o tamanho do binário. Fica a
seu critério.

> * Comandos que contem o sinal = na linha de comando. Por exemplo:
>
> BtnKrmFirewallSet=krm-firewall -s --action=set

Corrigi o Script.module para evitar este erro. O problema era o
comando "split", que divide linha inteira do arquivo de configuração
no sinal de "=". O caso é que se houver mais de um sinal de igual,
este comando irá dividir a linha em mais de 2 strings.

O que fiz foi adicionar um IF para ver se o array contem mais de 2
strings. Caso positivo, entra em um FOR que vai reunir todas as
strings além da primeira (nome do botão) em uma só juntando-as com
sinais de "=".

> Uma outra coisa que eu tentei, foi colocar linhas repetidas com o
> mesmo nome do botão para ver o que acontecia, e aparentemente o
> script sempre pega a última que tiver.

---Bom teste. Eu não tinha pensado nisso. É bom saber.---

========================================================================

Um outro ponto:

O seu script "gambler" instalado no /usr/bin possui as seguintes
definições e a função:
---------------------------------------------------------------------------------------------------------------
myname=`basename $0`
pkgname=$myname-common

conffile=/etc/$myname/$myname.conf
gbxfile=/usr/share/$myname/$myname.gbx
rcfile=~/.$myname/${myname}rc
foreground=0
ignore=0
pslist=''

debug=0
cmd_line="$@"

ignore=0
quiet=''

[ ! -f $rcfile ] && {
mkdir -p ~/.$myname
cp $conffile $rcfile
sed -i "s|^SOURCE_DIRECTORY=.*|SOURCE_DIRECTORY=/home/`getuser`/
Desktop|g" $rcfile
}
---------------------------------------------------------------------------------------------------------------

É preciso tirar aquele "gamblerrc" e inserir os novos arquivos ".conf"
no pacote deb para serem instalados na pasta "/etc/gambler". E mudar
as linhas "conffile" e "rcfile" para:

conffile="/etc/$myname/*conf"
rcfile=~/.$myname/

De modo que os arquivo conf sejam copiados para o HOME do usuário. Mas
isso você já sabe...

Um abraço,

Riceman

[buli]

Riceman,

não teve tempo de testar as mudanças por causa de um probleminha no
micro. Vou testar no final de semana, mas se vc. testou e deu certo,
não vejo mas motivo para adiarmos o lançamento. Em compensação, vou
deixar os debs e o repositório prontos.

Com relação às suas questões:

> ---Na realidade não há necessidade de renomear. Inclusive eu acho
> melhor deixar como ".conf" para ficar visível para o usuário que é uma
> configuração do painel.
> Note que no código que você alterou no Script.module você junta *
> (todos os arquivos independente do seu nome).
>
> SHELL "cat $HOME/.gambler/* >" & ConfFile WAIT

Você está certo. Na verdade não tem necessidade de renomear, mas acho
melhor deixarmos como rc por questões de organização e para seguir o
padrão do sistema. Por exemplo, na pasta do KDE ~/.kde/share/config/
é tudo rc.

Eu tomei providências para que o pacote deb instale as coisas nos
lugares certos: Os arquivos de configuração com extensão conf são
instalados na pasta /etc/gambler. Depois eles são copiados para a
pasta do usuário ~/.gambler/ como rc. Tudo isso o próprio pacote faz
na hora da instalação, graças ao getuser (que também coloca o ícone no
Desktop).

Além disso, o próprio script /usr/bin/gambler cada vez que é rodado
verifica que os arquivos rc estejam na pasta do usuário, e copia (como
rc) caso contrário, se foram apagados por acidente, por exemplo.

> É preciso arrumar no pacote de instalação para remover o gamblerrc que
> havia lá e deixar somente estes novos arquivos ".conf".

Acho que o pacote não deveria apagar nada na pasta do usuário, pois a
idéa é que ele costumize o painel de acordo com as suas preferências
usando apenas os arquivos rc, pois é somente neles que o usuário tem
permissão de escrita.

Se o pacote apagase esses arquivos, independemente da extensão ser
conf ou rc, então o usuário perderia todas as modificações que ele fez
a cada vez que reinstala o pacote, e teria que refazer tudo outra vez,
o que seria muito ruim e ficaria p... da vida com nós ;-)

Contudo, vc. está certo em colocar o fato que deve existir alguma
forma de atualizar tais arquivos, se uma versão mais nova e melhor for
instalada, exemplo. Mas esa atualização deve ser feita manualmente
pelo usuário, para evitar o tipo de situação que coloquei no
parárgrafo anterior.

Pensando nisso, eu acrescentei a opção --reconfig nas versões mais
atuais do script gambler que faz justamente isso. Ou seja, depois de
instalar o pacote, você deve rodar o comando:

gambler --reconfig

e todos os arquivos de config. novos na pasta /etc/gambler serão
copiados para a pasta ~/.gambler/ automaticamente como rc e
sobrescrevendo os antigos. De passagem, isso aplica-se somente para
nós que temos versões antigas de teste do gambler já instaladas. Quem
estiver instalando pela primeira vez não precissaria fazer tal coisa.
Além, disso acrescentei a opção --refresh que funciona igual mas SEM
sobrescrever os arquivos antigos.

> Encontrei um "erro" no arquivo main.conf. Não havia novas linhas
> vazias ao final do arquivo, de modo que quando o cat juntava ele com
> outro, a linha do primeiro botão ficava grudada com a última linha
> deste arquivo, gerando por sua vez uma linha com mais de um "=" que
> resultaria em um comando bem estranho com nome de botão no meio e
> tudo. O arquivo no pacote 1.0.56 já está corrigido.

Ok! Bem corrigido.

> Não entendi pra quê serviam as linhas abaixo, então simplesmente
> comentei. Não tive nenhum bug conforme dito no comentário.
> --------------------------------------------------------------------------------------------------------------------
> 'Da um tempo antes de processar o arquivo temporário, para evitar um
> bug.
> 'SHELL "sleep `grep ^SCRIPT_DELAY= $HOME/.gambler/gamblerrc|cut -d= -
> f2`"
> --------------------------------------------------------------------------------------------------------------------
> Talvez possa ser removido para limpar o código.

Teve de acrescentar isso para evitar um erro de "arquivo não
encontrado". Isso serve apenas para rodar o comando

sleep n

que tudo o que faz é interromper o processamento por n segundos. No
começo eu tinha colocado sleep 5, mas depois achei 5 seg. um tempo
excesivo e coloque como variável no arquivo de configuração, para
poder mudar a vontade.

No arquivo gambler.conf (ou gamblerrc) tem uma linha no começo, após
a seção "source", que consiste em:

SCRIPT_DELAY=3

O código que vc. postou lê o valor dessa variável e coloca o tempo no
comando sleep. Isso seria mais um exemplo do uso daquele truque das
aspas simples reversas.

> ---Concordo. Porém poste esta versão 1.0.56 nos arquivos deste grupo.
> Ela contém os melhoramentos mencionados aqui.---

Vou fazer as atualizaçoes no final de semana.

> ---Acho que deveríamos manter a numeração do Clica-Ai e liberar como
> 1.8. Por favor, atualize-o para ser baseado no Gambler 1.0.56 (não sei
> exatamente o que você alterou)

Idem. Na costumização para o Kurumin, mudei apenas aquilo que está
visible, o icone do tux e alguns dos textos no corpo principal do
painel.

> ---No caso das ComboBoxes não tem jeito executar usando LAST e Tag,
> visto que há mais de um valor que pode ser assumido. Neste caso é
> preciso manter a mesma estrutura que você tinha para o "gambler -b",
> porém chamando o Script.Call.
> Veja no código. Eu mantive a estrutura "gambler -b" comentada, visto
> que percebi que você manteve os códigos "gambler -b" independentes por
> botão, para poder fazer o chaveamento entre o uso do Script.module
> (adicionando o Grupo = Comando como você mencionou) e o "gambler -b".

Ok.

> Se vamos abrir mão totalmente do "gambler -b", podemos excluir todo
> este código. Isto vai reduzir ainda mais o tamanho do binário. Fica a
> seu critério.

A idéia seria de fato eliminar todo aquele código. De momento, acho
melhor deixar, por qualquer imprevisto, até ter o feedback de testes
mais extensivos.

> Corrigi o Script.module para evitar este erro. O problema era o
> comando "split", que divide linha inteira do arquivo de configuração
> no sinal de "=". O caso é que se houver mais de um sinal de igual,
> este comando irá dividir a linha em mais de 2 strings.
>
> O que fiz foi adicionar um IF para ver se o array contem mais de 2
> strings. Caso positivo, entra em um FOR que vai reunir todas as
> strings além da primeira (nome do botão) em uma só juntando-as com
> sinais de "=".

Ok. Vou testar.

Acho que isso já ficou respondido acima. Tem apenas uma observação. O
arquivo gambler.conf (ou gamblerrc) merece um tratamento especial pois
além de conter buttons e comandos, ele tem logo no começo duas seções
especiais "source" e "settings" que determinan certos parámetros e
variáveis globais do Gambler como um todo, inclusive os fontes. Por
isso ele é destacado com aquelas variáveis conffile e rcfile.

========================================================================

Tem mais uma observação que esqueci da outra vez:

O seu Script.module original do 1.0.54 para os ícones mágicos rodava
os comandos com um "xterm -e".

Eu tirei o xterm, pois a grande maioria dos comandos não precissar
rodar presa no terminal. Também não fiz questão de "consertar" isso,
pois acho que mesmo os scripts dos IM também não precissam, sendo
apenas uma "debug option" colocada pelo MMT.

Contudo, se alguem fizer questão, acho que no atual esquema do nosso
painel o mais apropriado seria jogar isso no aquivo de configuração,
por exemplo:

BtnInstalarPrograma=xterm -e /usr/local/bin/instalar-programa.


Bem acho que isso por enquanto. Estamos perto do final.

Abraços.

[Riceman]

Buli,

É isso aí, estamos quase no fim! E o projeto está ficando muito bom!

Vamos lá... respostas

> não tive tempo de testar as mudanças por causa de um probleminha no
> micro.

Fiz mais alguns testes sem problemas. Inclusive removi aquele RETURN
ConfFile que você mencionou e foi sem problemas.

> Você está certo. Na verdade não tem necessidade de renomear, mas acho
> melhor deixarmos como rc por questões de organização e para seguir o
> padrão do sistema. Por exemplo, na pasta do KDE ~/.kde/share/config/
> é tudo rc

Ok. Deixemos "rc" em nome do padrão do sistema.

> Eu tomei providências para que o pacote deb instale as coisas nos
> lugares certos: Os arquivos de configuração com extensão conf são
> instalados na pasta /etc/gambler. Depois eles são copiados para a
> pasta do usuário ~/.gambler/ como rc. Tudo isso o próprio pacote faz
> na hora da instalação, graças ao getuser (que também coloca o ícone no
> Desktop).

Maravilha!

> Além disso, o próprio script /usr/bin/gambler cada vez que é rodado
> verifica que os arquivos rc estejam na pasta do usuário, e copia (como
> rc) caso contrário, se foram apagados por acidente, por exemplo.

Beleza!

> Acho que o pacote não deveria apagar nada na pasta do usuário

Não foi bem isso que eu quiz dizer. Na realidade eu estava falando em
remover do projeto aquele arquivo único e mudar os códigos para
trabalhar com os vários ".conf". Mas pelo que entendi você já fez
isso.

> Contudo, vc. está certo em colocar o fato que deve existir alguma
> forma de atualizar tais arquivos, se uma versão mais nova e melhor for
> instalada, exemplo. Mas esa atualização deve ser feita manualmente
> pelo usuário, para evitar o tipo de situação que coloquei no
> parárgrafo anterior.

> gambler --reconfig
> opção --refresh

Na realidade eu não tinha pensado nisso, mas foi uma ótima idéia.

> A idéia seria de fato eliminar todo aquele código. De momento, acho
> melhor deixar, por qualquer imprevisto, até ter o feedback de testes
> mais extensivos.

Concordo.

> O seu Script.module original do 1.0.54 para os ícones mágicos rodava
> os comandos com um "xterm -e".
> Eu tirei o xterm, pois a grande maioria dos comandos não precissar
> rodar presa no terminal.

Realmente não precisa. Porém rodando dentro dele, fica visível ao
usuário o que o sistema está fazendo. Foi apenas esse o motivo, deixar
o sistema mais transparente ao usuário. (Eu pessoalmente não gosto de
rodar algo que não sei o que está fazendo na minha máquina)

> Contudo, se alguem fizer questão, acho que no atual esquema do nosso
> painel o mais apropriado seria jogar isso no aquivo de configuração,
> por exemplo:
>
> BtnInstalarPrograma=xterm -e /usr/local/bin/instalar-programa.

Não sei se seria a melhor solução. Daria um grande trabalho. Podemos
fazer como fiz com os Urls, veja abaixo.

====================================================================

Resolvi o caso de execução dos Urls que tinha mencionado antes. Agora
tudo está rodando através do "Script.module".

Criei um arquivo chamado Urls.conf, contendo o mesma informação que no
Url.module e uma linha a mais "Navegador=firefox". Deste modo o
usuário pode determinar seu navegador favorito e editar os urls.

Nos botões mantive o grupo UrlGuias, pois eles rodam uma nova função
que adicionei no Script.module chamada "GoToUrl" que é tão simples
quanto a Script.Call. A única diferença é que ela concatena o
Navegador com o Url a acessar.

Nos códigos dos formulários onde há urls, eu mantive o código anterior
comentado e inseri uma nova linha chamando esta nova função, para você
ver a diferença. Além disso ainda não deletei o Url.module, mas ele
não é mais utilizado.
Você pode remover as linhas comentadas das funções dos urls e excluir
o Url.module antes de liberar se quiser.
Testei a alteração e funcionou sem problemas.

====================================================================

Voltando ao tema do "xterm -e", podemos fazer o mesmo aproach. Inserir
uma linha

"Terminal=xterm -e" ou somente "Terminal=" para rodar direto

Deste modo mudaríamos a função do comando da mesma forma que a dos
Urls, porém para concatenar com o "Terminal" ao invés do "Navegador".
Assim no primeiro caso acima, rodaria os comando dentro do xterm e no
segundo rodaria direto. Só teríamos que adicionar um código Trim
circundando toda a concatenação para eliminar o espaço (" ") inicial
caso o terminal seja "vazio" (iria concatenar "vazio" + " "(espaço) +
<comando>). Logo a linha ficaria assim:

SHELL Trim(Links("Terminal") & " " & Links(BtnName))

--------------------------------------------------------------------------------------------------------------------------------------

Antes de liberar eu gostaria de te pedir para empacotar isso tudo e
publicar no nosso grupo da mesma forma que você fez com o 1.0.53, para
primeiro podermos testar a instalação do "zero" e ver se está tudo ok.
Pois como você mesmo comentou fizemos várias alterações com uma versão
antiga instalada.

Grande Abraço!

Riceman

[buli]

Riceman,

pegui as últimas modificações e vou verificar tudo o mais brevemente
possível.

Com relação às questões mais urgentes do xterm:

> Não sei se seria a melhor solução. Daria um grande trabalho. Podemos
> fazer como fiz com os Urls, veja abaixo.

Podemos usar o sed outra vez para substuir "=" por "=xterm -e" no
arquivo iconesmagicos.conf, seria bem tranquilo.

> Criei um arquivo chamado Urls.conf, contendo o mesma informação que no
> Url.module e uma linha a mais "Navegador=firefox". Deste modo o
> usuário pode determinar seu navegador favorito e editar os urls.

Perfeito!

> Voltando ao tema do "xterm -e", podemos fazer o mesmo aproach. Inserir
> uma linha
>
> "Terminal=xterm -e" ou somente "Terminal=" para rodar direto
>
> Deste modo mudaríamos a função do comando da mesma forma que a dos
> Urls, porém para concatenar com o "Terminal" ao invés do "Navegador".
> Assim no primeiro caso acima, rodaria os comando dentro do xterm e no
> segundo rodaria direto. Só teríamos que adicionar um código Trim
> circundando toda a concatenação para eliminar o espaço (" ") inicial
> caso o terminal seja "vazio" (iria concatenar "vazio" + " "(espaço) +
> <comando>). Logo a linha ficaria assim:
>
> SHELL Trim(Links("Terminal") & " " & Links(BtnName))

Esta segunda solução é mais elegante que a anterior, e além disso pode
ser generalizada para outros casos. Se vc. acha que não vai dar muito
trabalho, podemos adota-la mesmo.

Lembre-se que que os botões dos IM pertencem ao grupo Instalar e todos
os outros ao grupo Comando. Se mal entendi, vc. planeja fazer que o
primeiro grupo tenha "Terminal=xterm -e" no entanto que o segundo
grupo tenha "Terminal=", é correto? Se for assim, essa é a parte que
não saberia fazer. Mas se vc. acha que consegue resolver sem muito
esforço, por mim tudo bem.

> Antes de liberar eu gostaria de te pedir para empacotar isso tudo e
> publicar no nosso grupo da mesma forma que você fez com o 1.0.53, para
> primeiro podermos testar a instalação do "zero" e ver se está tudo ok.
> Pois como você mesmo comentou fizemos várias alterações com uma versão
> antiga instalada.

Pode deixar que faço. Já tinha os deb quase prontos, mas com a versão
1.0.55. Vour ter que atualiza-los, mas acho que podemos acabar com
tudo isso logo.

Abraços!

[Riceman]

Buli,

Acho que esta é a versão para liberarmos. Vide comentários abaixo:
(Postei o arquivo aqui no grupo)

> Esta segunda solução é mais elegante que a anterior, e além disso pode
> ser generalizada para outros casos. Se vc. acha que não vai dar muito
> trabalho, podemos adota-la mesmo.
>
> Lembre-se que que os botões dos IM pertencem ao grupo Instalar e todos
> os outros ao grupo Comando. Se mal entendi, vc. planeja fazer que o
> primeiro grupo tenha "Terminal=xterm -e" no entanto que o segundo
> grupo tenha "Terminal=", é correto? Se for assim, essa é a parte que
> não saberia fazer. Mas se vc. acha que consegue resolver sem muito
> esforço, por mim tudo bem.

Na realidade eu não tinha pensado nisso também, mas é uma boa idéia
para não ficar aparecendo uma janela do xterm ao abrir um diálogo
perguntando para desligar o computador. Consegui implementar o esquema
o xterm sem muito trabalho e já removi o Url.module.

O que fiz?

1) Incluí no arquivo "gambler.conf" sob "#Settings" a linha:
TERMINAL=xterm -e
Esta linha fica sempre fixa, ou especificando o terminal que o
usuário prefira.

2) Alterei a função Script.Call no módulo da seguinte forma:

Adicionei um parâmetro opcional chamado "Encapsulate" (que por padrão
é falso) que definirá se o comando será executado dentro de um
terminal ou não.
Adicionei um teste na função para saber se concatenar com o Terminal
ou com <Vazio> e a concatenação em si dentro do SHELL.

Assim:

PUBLIC SUB Call(BtnName AS String, OPTIONAL Encapsulate AS Boolean =
FALSE)
DIM Terminal AS String

Links=ReadConfs()
Terminal=If(Encapsulate, Links["TERMINAL"], "")
SHELL Trim(Terminal & " " & Links[BtnName])

END

3) Nas funções de chamada dos Ícones Mágicos (do grupo Instalar)
adicionei o parâmetro TRUE.
Assim: Script.Call(LAST.Tag, TRUE)

Obs.: Nas funções do grupo "Comando" não mexi. Por isso defini como
parâmetro opcional (para não precisar mexer em tudo)

Deste modo os comandos dos botões nunca serão executados dentro de um
terminal e os Ícones Mágicos, sempre. Quero dizer, sem opção de
configuração pelo usuário do quê rodar encapsulado, apenas a escolha
do Terminal.
Acredito que faz sentido desta forma.

> Pode deixar que faço. Já tinha os deb quase prontos, mas com a versão
> 1.0.55. Vour ter que atualiza-los, mas acho que podemos acabar com
> tudo isso logo.

Maravilha ficarei esperando seu pacote.

------------------------------------------------------------------------------------------------------------------------

Outra coisa que não tinha mencionado. Eu corrigi o formulário de
créditos, pois meu e-mail estava errado.

Abraço,

Riceman

[buli]

Riceman,

testei o esquema que vc. implementou para as URL e comandos com = e
ficou ótimo!. Vc. tem feito um exelente trabalho.

O esquema do xterm testei superficialmente, mas aparentemente funciona
bem.

> Acho que esta é a versão para liberarmos.

Concordo. Tem apenas duas questões:

1. Favor confirme se as modificações que vc. fez do 1.0.56 para o
1.057 foram apenas as seguintes:

a. Linha "TERMINAL=xterm -e" acrescida no arquivo gambler.conf

b. Modificações várias no arquivo Script.module

c. Troca de "Script.Call(LAST.Tag)" para "Script.Call(LAST.Tag,
TRUE)" em todos os 8 form class dos ícones mágicos


2. O Script. module não apaga os arquivos temporários criados na
pasta /tmp. Se for possível, gostaria que vc. confirma-se isso abrindo
a pasta /tmp com o Konqueror no seu sistema. Eu posso estar com as
permissões erradas, mas acho que não.

Isso não atrapalha em nada o funcionamento do painel, mas acho uma
questão de "boa etiqueta" para os aplicativos apagarem os arquivos
temporários que eles criam.

Por algum motivo que eu não saberia dizer, uma solução que eu testei e
funcionou no caso do Script.module foi declarar como public a variável
ConfFile e acrescentar o comando para remover em cada uma das funções
Call e GoToUrl. Como vc. é o expert nessa questão, postei o
Script.module modificado para vc. conferir.

Da minha parte não tenho mais nada a sugerir.

Fico no aguardo da sua confirmação. Se for só isso, pode deixar que eu
implemento as modificações e depois posto o hipotético 1.0.58 que, se
não acontecer nenhum imprevisto, poderia ser o release final mesmo.

Abraços.

[Riceman]

Buli,

Respondendo suas questões:

> 1. Favor confirme se as modificações que vc. fez do 1.0.56 para o
> 1.057 foram apenas as seguintes:
>
> a. Linha "TERMINAL=xterm -e" acrescida no arquivo gambler.conf
>
> b. Modificações várias no arquivo Script.module
>
> c. Troca de "Script.Call(LAST.Tag)" para "Script.Call(LAST.Tag,
> TRUE)" em todos os 8 form class dos ícones mágicos

Confirmado. Foi realmente só isso.

> 2. O Script. module não apaga os arquivos temporários criados na
> pasta /tmp. Se for possível, gostaria que vc. confirma-se isso abrindo
> a pasta /tmp com o Konqueror no seu sistema. Eu posso estar com as
> permissões erradas, mas acho que não.

Talvez sejam realmente suas permissões. Eu já tinha testado isso antes
de publicar 1.0.57.

> Isso não atrapalha em nada o funcionamento do painel, mas acho uma
> questão de "boa etiqueta" para os aplicativos apagarem os arquivos
> temporários que eles criam.

Também concordo com você.

> Por algum motivo que eu não saberia dizer, uma solução que eu testei e
> funcionou no caso do Script.module foi declarar como public a variável
> ConfFile e acrescentar o comando para remover em cada uma das funções
> Call e GoToUrl. Como vc. é o expert nessa questão, postei o
> Script.module modificado para vc. conferir.

Aqui no meu caso funcionou sem estas medidas. Mas de qualquer modo
isto não altera muita coisa no código. Se assim parece ser mais
robusto, deixe-o assim.

> Fico no aguardo da sua confirmação. Se for só isso, pode deixar que eu
> implemento as modificações e depois posto o hipotético 1.0.58 que, se
> não acontecer nenhum imprevisto, poderia ser o release final mesmo.

Beleza! Manda bala!

P.S.: Dá uma olhada no outro post que eu criei.

Abraço,

Riceman

[buli]

Riceman,

finalmente postei a versão 1.0.58 em debs.

1. Usando o comando dpkg -i <pacote.deb> instale na seguinte ordem:

getuser
krx-libs
krx-utils
gambler-common
gambler-bin

Antes do gambler-common apage ou renomeie a pasta ~/.gambler. Esse
pacote também faz algumas perguntas na hora da instalação e edita o
arquivo de configuração segundo as respostas. Isso inclui agora em
carater experimental no empacotamento deb.

2. Mudanças: são questões mais "burocráticas" que não afetam o
funcionamento (não deveriam afetar, pelo menos):

a. O arquivo urls.conf foi absorvido pelos outros arquivos de
configuração. Fiz isso para preservar a independência dos módulos e
para simplificar também, pois assim cada módulo fica com apenas um
arquivo de config.

b. O antigo nome reservado BtnInfoUrl* foi substituido por BtnURL*.
Acho que assim fica mais claro, pois agora esses botões são
configuráveis, no entanto que BtnInfo* e BtnForm* não são.

c. O arquivo gambler.conf foi dividido em 2 partes: as config. globais
(settings e source) agora ficaram isoladas num arquivo nomeado
global.conf, no entanto que os botões e urls ficaram no gambler.conf
mesmo.

d. Os binários agora não tem mais a extensão .gbx que eu tinha
colocado antes.


Já debianizei os fontes e o clica-ai e seus fontes também. Não postei
tudo junto porque excede o tamanho máximo de 10MB.

Bem acho que isso, qualquer dúvida postem.

[buli]

Não consegui dar upload aqui no google e portanto coloquei todos os
pacotes no repositório. Já testei e todos instalam bem inclusive o
clica-ai e clica-ai source.

[Riceman]

> finalmente postei a versão 1.0.58 em debs.

Ótimo trabalho, Buli!

O instalador fazendo perguntas no processo ficou ótimo. Só precisa
adicionar 2 opções na hora de decidir se substituir os arquivos de
configuração ou não: Substituir Todos e Manter Todos. Dizer Yes ou No
em cada caso fica chato. Mas pode ser pra próxima versão. Visto que
para os usuários é a primeira vez que vão instalar o painel "Powered
by Gambler".

Pode publicar! Porém seguem alguns lembretes:

1) Precisa pedir para o passarín atualizar o tópico no fórum.

2) É preciso mencionar que o projeto do Clica-ai agora é baseado no
projeto Gambler que foi criado para ser um painel mais genérico e
adaptável a outras distros.

3) É preciso mencionar isto tanto no Fórum como no nosso Wiki.

Aline,
4) Tenho certeza que você pode preparar um texto legal para introduzir
o projeto Gambler. Pode usar os posts de Documentação do Buli como
base. Lá estão mais ou menos resumidas as mudanças do Clica-ai 1.7.1
para 1.8 e o Gambler.

Precisamos agora parar um pouco com o desenvolvimento e pensar nas
direçoes futuras do projeto. Como vocês devem ter notado o Gambler 2.0
já foi lançado como estável. Ele pode importar os projetos do 1.0.15,
logo não seria problema continuar o desenvolvimento usando a nova
versão (A IDE está muito, muito, mas muito melhor).

Vou abrir um novo post para discutirmos os próximos passos.

Parabéns pelo ótimo trabalho de todos!

Abraços!

Riceman

[buli]

Riceman, com relação às suas dúvidas:

> Só precisa
> adicionar 2 opções na hora de decidir se substituir os arquivos de
> configuração ou não: Substituir Todos e Manter Todos. Dizer Yes ou No
> em cada caso fica chato.

Com relação aos arq. de conf. da pasta ~/.gambler, o instalador copia
apenas os que estiverem faltando e nunca sobrescreve nada. Substituir
algo que já exista é uma tarefa reservada exclusivamente ao usuário,
por motivos que já comentamos em um post anterior. Para isso existem
os comandos:

gambler --reconfig : copia tudo sobrescrevendo.

gambler --refresh : copia o que estiver faltando sem sobrescrever
(como faz o instalador).

Acho que vc. está se referindo aos arquivos de conf. da pasta /etc/
gambler. Isso é uma questão do sistema de gerenciamento de pacotes do
Debian: tudo que estiver na pasta /etc/ é marcado automaticamente como
arquivo de configuração na hora de criar o pacote. Ao instalar, o
próprio dpkg faz as perguntas sobre substituir pela versão do
"mantenedor o pacote" ou preservar pela versão existente. Eu não tenho
como controlar isso.

Bem, na verdade existe uma maneira de fazer isso: fixar o valor da
variável de ambiente DH_COMPAT para 3 ou menor. Dessa maneira, os
scripts que criam o pacote agem como se fossem versões mais antigas, e
nessas versões mais antigas os scripts da pasta /etc/ não são marcados
automaticamente como arq. de conf. Honestamente, não acho uma solução
recomendável, o valor recomendado é DH_COMPAT=5, que é o que eu sempre
uso.

Podemos bolar um outro esquema, mas acho melhor por enquanto deixar
que o sistema de gerenciamento de pacotes do Debian faça seu
trabalho.

--------------------------------------------------------------------------------------------------------------------------------

Uma outra questão: quando o instalador mostra a lista de navegadores
para o usuário escolher é muito probável que o firefox não seja
incluido na lista embora esteja instalado no sistema.

Isso acontece se você tiver instalado o firefox "por fora" do sistema
do gerenciamento do Debian. Ou seja, sem usar um pacote .deb, ou com
algum pacote deb que não for do Debian "de verdade", feito de
"qualquer jeito".

Isso porque a lista de navegadores é construida usando o update-
alternatives, que é uma das "frescuras" do Debian. Veja a saida dos
comandos:

update-alternatives --display x-www-browser

e

update-alternatives --display www-browser

Trata-se de uma pequena "maldade" da minha parte para usuários "Debian-
não-politicamente-corretos" que podemos corregir em futuras versões.

Abraços.

[Riceman]

> Acho que vc. está se referindo aos arquivos de conf. da pasta /etc/
> gambler. Isso é uma questão do sistema de gerenciamento de pacotes do
> Debian: tudo que estiver na pasta /etc/ é marcado automaticamente como
> arquivo de configuração na hora de criar o pacote. Ao instalar, o
> próprio dpkg faz as perguntas sobre substituir pela versão do
> "mantenedor o pacote" ou preservar pela versão existente. Eu não tenho
> como controlar isso.

> Podemos bolar um outro esquema, mas acho melhor por enquanto deixar
> que o sistema de gerenciamento de pacotes do Debian faça seu
> trabalho.

Ok, concordo plenamente. Eu não sabia que era o dpkg que fazia este
gerenciamentos automatico. Na realidade eu gostei dele apresentar esta
escolha! Deixemos assim.

> --------------------------------------------------------------------------------------------------------------------------------
> Uma outra questão: quando o instalador mostra a lista de navegadores
> para o usuário escolher é muito probável que o firefox não seja
> incluido na lista embora esteja instalado no sistema.

Na realidade ele não está. Quem está instalado no Kurumin 7 é o
Iceweasel. Você
pode chamá-lo através do comando "firefox" devido à uma "malandragem"
do Morimoto. Veja em /usr/bin que o comando "firefox" nada mais
é que um link simbólico apontando para o executável do Iceweasel.
Rode "la /usr/bin/fire*".

> Trata-se de uma pequena "maldade" da minha parte para usuários "Debian-
> não-politicamente-corretos" que podemos corregir em futuras versões.

Ok, podemos deixar assim no momento.

Abraços,

Riceman