Ver esta página "cronogramas e metas para o clica-ai"

[Passarin Jr.]

Clique em http://groups.google.com/group/equipe-clica-ai/web/cronogramas-e-metas-para-o-clica-ai
ou copie e cole a hiperligação na barra de endereço do browser se não
funcionar.

[buli]

Até que tinha ficado pensando como fazer o painel Clica-ai mais
configurável, inclusive mesmo dentro do próprio Kurumin, mas a mesma
coisa pode ser aproveitada para uma eventual migração para outras
distros (pelo menos Debian-like, para começar).

No fundo, acho que vocês concordam, o que o painel faz é servir de
front-end para os scripts do K7. Quando o botão, digamos, "Configurar
Rede" é clicado o que acontece é que o script "configurar-rede" é
rodado, e assim com tudo mais.

Vamos supor que, mesmo dentro do K7, alguem prefere configrar a rede
com um outro script, digamos "minha-rede" em lugar daquele citado em
primeiro lugar. O que poderia ser feito?

Esteve pensando varias coisas. A idéia que eu achei mas adequada por
enquanto seria a seguinte:

Cada um dos botões do clica-ai receberia um label bem genérico, por
exemplo, "REDE". Quando você clicar nesse botão seria rodado um script
também "genérico" denominado "botão-rede" por exemplo.

Agora bem, esse tal arquivo botão-rede seria na verdade um link
simbólico apontando para o verdadeiro script "configurar-rede".

Para o usuário poder configurar a vontade, teria que existir ainda um
arquivo de configuração, por exemplo /etc/clica-ai.conf, que teria
que ter uma linha mais ou menos assim:

REDE=configurar-rede

Para mudar o script o usuário teria que editar esse arquivo trocando
para:

REDE=minha-rede

O wrapper /usr/bin/clica-ai que eu fiz, no fundo é um script "burro"
que tudo o que faz é rodar o executável do gambas. Mas ele poderia ser
modificado para que antes de rodar o binário do gambas, leia o arquivo
de configuração e, se for o caso troque o link simbólico de botão-rede
para minha-rede.

A vantagem disso seria que todas as mudanças nascem e morrem fora do
binário, que permaneceria completamente inalterado. O desvantagem
seria que o sistema ficaria cheio de link simbólicos, mas até agora
não consigo ver nenhum mal nisso.

Em fim, é apenas uma sugestão. Gostaria conhecer sua opinião.

Acho que implementar isso daria um trabalho danado, principalmente
para vocês, por tanto parece-me que as coisas teriam que ser
planejadas com bastante calma.

Seria bom consultar também a opinião de algum "profissional" da área,
se vocês, Passarim ou Riceman, conhecem alguem, ou consultar até para
o próprio Morimoto mesmo, na maior "cara de pau" se for o caso.

Abracos.









On Nov 27, 12:15 pm, "Passarin Jr." <passarin...@gmail.com> wrote:
> Clique emhttp://groups.google.com/group/equipe-clica-ai/web/cronogramas-e-meta...

[Passarin Jr.]

hum...preciso que Riceman se manifeste a respeito...de uma certa
forma buli, o usuário pode usar outro script, basta modificar o
original do Kurumin e manter o mesmo nome...
No caso do port Debina-like o problema é que muita coisa no Kurumin
vem instalada por padrão precisando apenas ser ativada, como no caso
dos softmodens...isso complica as coisas pois teríamos que desenvolver
um script do zero, do tipo, achar um ftp do modem usado no Kurumin,
baixar o arquivo tar.gz e intalá-lo. teoricamente é simples, mas
teríamos que ter várias pessoas testando estes scripts e outras mais
desenvolvendo esses scripts pois creio que a nossa equipe é pequena
pra tamanha responsabilidade..no Fórum GDH, tem o S-K e o matheus2 que
gostam de escrever scripts, talvez eles possam ajudar...

[buli]

O que você propõe seria extremamente interessante, mas é um projeto
bem mais ambicioso.

Para falar verdade já fiquei pensando nisso também, mas em um outro
contexto por assim dizer.

O que eu estava interessado era em fazer com que o K7 seja
*completamente* atualizável via apt-get. Isso acabaria de vez com
aquelas polêmicas inúteis do forum sobre atualizações, live-update,
etc. etc. Com efeito, usando o apt-get o sistema poderia ser
atualizado todo dia se for o caso, desde que as mudanças sejam
disponibilizadas no repositório oportunamente.

Eu estudei o caso do Kurumin Light 7.0b6. Ele tem aprox. 640 pacotes
deb. Desse total, aprox. uns 580 são do Debian e podem ser atualizados
normalmente pelo apt-get.

Tem um grupinho de aprox. 20 pacotes que são do Kanotix/Knoppix, que
você consegue on-line. Porém muitos deles foram significativamente
modificados por Morimoto, e ai já não é nem um pouco recomendável
instalar via apt-get.

Existem ainda os "scripts do kurumin" que são mais de 300 scripts, se
não me engano, populando a pasta /usr/local/bin. Esses scripts não
constam em lugar nenhum exceto no próprio K7.

O que eu fiz foi dividir esses scripts em grupos temáticos, por assim
dizer e criar pacotes deb com eles, que podem ser colocados no
repositório. Com tudo isso o sistema ficaria completamente atualizável
via apt-get.

Mas o trabalho que eu fiz ainda está longe de ser acabado. Para falar
verdade, fiz tudo aquilo que era prioritário para meu interesse e
dexei o resto completamente inacabado.

Aliás, fazer tudo isso eu sozinho seria imposível. Além das pessoas
que você citou, acho que tem mais pessoas no forum capacitadas.
Trabalhando num projeto comunitário dessa magnitude, acho que tudo
mundo ficaria empolegado e poderia ser feito em 6 meses ou no máximo
um ano, mesmo com um grupo reduzido de pessoas.

Alguns dos grupos temáticos que eu identifiquei, por exemplo, foram:

* clica-aki (o painel original)
* icones-mágicos (são aprox. 130 script, seria o grupo mais numeroso)
* kurumin-remote (servers e serviços para conexão remota)
* kurumin-media (video, imagem, som, etc)
* kurumin-modems (modems)
* kurumin-harware (supporte "não-problemático" para hardware)
* etc. etc.

Alguns scripts joguei fora porque encontrei aplicativos do KDE,
bastante leves, aliás, que faziam a mesma coisa, por exemplo,
kshutdown, kuser, kdessh. Tudo isso pode ser discutido e remanejado.
de ser discutido e remanejado. O importante no caso seria formar um
equipe e mandar bala no projeto.

[Riceman]

Olá Passarín e Buli,

Gostei da idéia, irá flexibilizar muito nosso código. E transformando
os scripts do morimoto em pacotes DEB instaláveis, o tornaremos
independente da versão do Kurumin e talvez até de distribuição (dentro
de certos limites).

Mas comentando a sugestão do Buli (3 posts acima). Não há necessidade
de ter tudo isso de links simbólicos. Na realizade poderemos reduzir
drasticamente o código utilizando as ferramentas do Gambas que
mencionei no Tópico sobre a propriedade Tag.

Porém como são muitos componentes definir Tags para cada um não seria
muito inteligente e daria muito trabalho, assim podemos utilizar o
próprio nome dos componentes que já está definido e criar uma
estrutura conforme descrito à seguir.

O arquivo "clica-ai.conf" seria basicamente composto de linhas assim:

<Nome do Botão>=<Endereço do Script>

Podemos incluir comentários para facilitar para o usuário e filtra-los
do código mais pra frente (Siga lendo pra entender este comentário).

No código iremos ler o arquivo linha a linha e quebrá-la em duas
strings tendo como separador o "=". (Aqui é que teríamos que filtrar
as linhas de comentários, sem "=", mas isto é muito simples). Assim
teremos uma string com o nome do botão e outra com o endereço do
script que ele deve chamar para cada linha do arquivo de configuração.
Com estas 2 strings podemos criar uma coleção (que nada mais é que um
array ou vetor cujos índices podem ser textos) relacionando o
"Endereço do Script" com o "Nome do Botão". E no código do botão
chamar o valor dentro desta coleção correspondente ao botão.

Com isso podemos também utilizar a propriedade Group dos botões e
reduzir o código drásticamente para funções similares, por exemplo,
todos os Ícones Mágicos que apenas chamam scripts diferentes dentro do
"xterm". Cada formulario poderia ser reduzido uma única função para
todos os botões "Instalar". Com isso reduziríamos mais ainda o tamanho
do pacote.

Este código pode ser "genérico" de tal modo que crie as relações Nome/
Endereço indefinidamente até o fim do arquivo, ou seja, caso criemos
novos botões e formulários bastaria adicionar a linha correspondete no
arquivo de configuração e adicionar o botão no Grupo correto, e o
resto se auto-adapta automaticamente.


Segue um exemplo do código abaixo:
----------------------------------------------------------------------------------------------
PUBLIC Links AS Collection 'declara a coleção
PUBLIC CONST ConfAddr AS String = "/usr/share/clica-ai/clica-ai.conf"
'define o endereço do arquivo de configuração

PUBLIC FUNCTION StartLinksCollection() AS Collection 'função que cria
a coleção

DIM Confs AS File 'declara o manipulador do arquivo
DIM txtLine AS String 'armazena o texto da linha
DIM TempStr AS String[] 'armazena o texto da linha quebrado no
"="
Links = NEW Collection 'inicializa a coleção

OPEN ConfAddr FOR READ AS Confs 'abre o arquivo para leitura
DO WHILE NOT Eof(Confs) 'repete o código abaixo
até terminar o arquivo (Eof=End-of-File)
LINE INPUT #Confs, txtLine 'Lê uma linha do
arquivo
TempStr=Split(txtLine,"=") 'Quebra a linha em
2 strings separando no "="
Links.Add(TempStr[1], TempStr[0]) 'Adiciona as informações
na coleção (primeiro o "Valor" depois a "Chave")
LOOP
CLOSE Confs 'Fecha o
arquivo

RETURN Links 'Retorna a
coleção

END

PUBLIC FUNCTION Call(BtnName AS String)
SHELL "xterm -e " & Links[BtnName] 'chama o script
definido na coleção para o botão dentro do xterm. Cada Grupo dentro
dos Forms Icones Mágicos iria chamar esta função.
END
----------------------------------------------------------------------------------------------

Eu acredito que é o modo mais fácil e flexível de fazer esta
alteração. O que acham?

Se vocês concordam com essa estrutura posso ir criando-a aos poucos.
Mas vai levar seu tempo para criar este arquivo da primeira vez (são
muitos botões). Podemos também fazer uma divisão por formulários e
cada um criar uma parte deste arquivo. Depois eu junto tudo num só e
integro no código.

Fico no aguardo de suas sugestões.

Abraço,

Riceman

[Riceman]

"Porém como são muitos componentes definir Tags para cada um não seria
muito inteligente e daria muito trabalho, assim podemos utilizar o

próprio nome dos componentes que já está definido..."

Ok, pessoal

Achei que daria certo mas testando não funcionou. Aparentemente os
objetos no Gambas não permitem acessar seu próprio nome através de uma
propriedade Name (por exemplo).

Procurei por isto não consegui achar uma forma de acessá-lo via
código. Então terei que definir Tags iguais ao nome do Botão para
funcionar, mas fora este trabalho o resto funciona perfeitamente.

Só pra adicionar esta informação.

Abraços,

Riceman

[Passarin Jr.]

Tudo bem, Riceman....mas qual a utilidade prática disso? Como eu disse
acima pra usar outro script, basta que o usuário troque o conteúdo do
original pelo modificado por ele...
mas se desta maneira dermos um passo pra tornoar o Clica-aí portável,
então manda ver...
Você parece entender muito de programação orientada a objetos e eu
estou apenas engatinhando. O que eu acho que deveria ser o foco
principal a médio e longo prazo é realmente a portabilidade. Na
verdade digo isto pois mandei um e-mail pro Morimoto falando do clica-
ai e ele respondeu dizendo que não sabe ao certo qual será o futuro do
Kurumin e sugeriu que nós tentássemos adptar o painel pra outras
distros também , pois assim o nosso projeto teria um alcanse maior...
E então? o que faremos?

[Riceman]

"Tudo bem, Riceman....mas qual a utilidade prática disso? Como eu
disse
acima pra usar outro script, basta que o usuário troque o conteúdo do
original pelo modificado por ele..."

Com certeza é uma solução, porém fica uma coisa meio "gambiarra", não
acha? Um arquivo de configuração com certeza é algo mais profissional
e dá uma imagem de flexibilidade do software e não de enganá-lo
colocando outros arquivos no lugar dos quais ele aponta (isso é
artifício pra enganar o Burrindows).

Além disso muitas vezes os usuários não querem substituir os arquivos
originais do sistema (eu sou um cara assim).

É claro que você percebeu que os links não precisam necessariamente
apontar para o /usr/local/bin/, podem apontar para a pasta do clica-ai
no share ou onde quer que o usuário deseje (até mesmo seu home), basta
apenas digitar o endereço completo. Observando que para pastas no PATH
não é necessário o caminho completo como os arquivos no /usr/local/
bin/, mas acho por bem deixar completo no arquivo de configuração,
para que os usuários que desejem personalizar este arquivo
intuitivamente preencham o caminho completo para seu script desejado.

Quanto à portabilidade, é como comentei antes, com este arquivo de
configurações e os scripts do Kurumin em pacotes instaláveis, estamos
bem independentes, presos apenas aos pacotes do KDE e à distribuições
descendentes do Debian (me corrijam se eu estiver errado).


Outra Sugestão:

Como estamos colocando os scripts em pacotes instaláveis (no /usr/
share/clica-ai), podemos transformar os "scripts embutidos no
código" (daqueles botões que têm várias linhas de comandos SHELL) em
arquivo de scripts a serem instalados share (como fizemos com o
"ajustar-frequencia") e chamar estes scripts através do arquivo de
configuração.

Isto teria duas grandes vantagens:
1) Reduziria o tamanho do código e por fim do arquivo final
2) Abriria os códigos destes scripts para os usuários estudarem e
entederem como tudo está funcionando, assim como os scripts do /usr/
local/bin/ do Morimoto (aprendi muito fuçando lá), só que nem tudo
está lá, como discutimos antes, há coisas embutidas no Kommander (que
quase ninguém fuça). Isto tornaria nosso painel ainda mais aberto,
compreensível (para os interessados), flexível e personalizável.

Já que vamos fazer um grande trabalho de redefinir a maior parte do
código do painel, que já façamos tudo de uma vez.

Concordam?



Saudações,

Riceman

[Airton Santana]

Tudo bem Riceman, pode tocar o bonde pra frente, mas lembre-se de documentar.
Primeiro, porque nós mesmos precisamos entender o esquema utilizado e
depois porque sem uma boa documentação ninguém irá chegar a aproveitar
desta flexibilização.

Em 02/12/07, Riceman<andrerf...@hotmail.com> escreveu:

[buli]

Os dois tipos de tarefas dariam um trabalho danado.

Acho que na abordagem de Passarim, para portar o painel primeiro
teriamos que portar todo o Kurumin 7, ou grande parte dele, e depois o
painel acompanharia como "bonus", por assim dizer. Não é uma coisa
ruim, pelo contrário, como já disse no meu último post, mas acho que
requere um equipe "multidisciplinar", com mais pessoas.

Até não reunir interessados que possam ajudar no K7, acho que a gente
teria que se focalizar no painel em sim mesmo:

Prioridade 1: Deixar ele completamente funcional no K7, e fazer
"publicidade" para os usuários migrarem do clica-aki para o clica-ai.
Desde que eu me recordo, o Morimoto está sempre dizendo, em sites ou
entrevistas, que ele não tempo para o Kurumin, mas o projeto de alguma
maneira continua.

Prioridade 2: O "novo" painel configurável. Parece-me que ele teria
ser quase reconstruido de zero, mas esso pode ir sendo feito aos
poucos. O fato do Kurumin estar em risco de continunidade acho um
incentivo a mais para se concentrar no painel e não na plataforma.

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

Mas, como já disse, o nosso lance deveria ser o painel mesmo. Usar o
fato que o Gambas serve para gtk ou qt, tentando aproveitar as brechas
do KDE ou gnome e focalizar na leveza. Por exemplo:

Problema: Não existe uma interface gráfica para atualizar o Firefox da
Mozilla Fundation.
Solução: O painel cria uma, como o Passarim está fazendo com o
clickzilla ahora. (aliás, Passarin, tenho programas na linha de
comando que atualizam até o Swiftfox, inclusive em português).

Problema: Não existem uma interface gráfica para criar um CD ou
disquete do Grub.
Soluçaõ: o painel cria uma. Também sei como fazer.

Problema: Para criar um CD do apt-get existe uma interface gráfica
denominada apt-on-cd, não sei se conhecem, mas no K7 resulta
necessário baixar como 50 MB em pacotes, pois é uma interface GTK.
Solução: Criar um CD do apt é bem simples, como criar um repositório e
colocar no CD, por assim dizer. O painel poderia incorporar uma
também.

E acho que assim poderia ser feito com tudo.

Paralelamente, aos pocos, vamos portando também alguns dos scripts do
K7. Acho que os mais importantes são os que mexem com configuração de
rede, servidores, e suporte a hardware.

On Dec 2, 9:51 pm, "Airton Santana" <passarin...@gmail.com> wrote:
> Tudo bem Riceman, pode tocar o bonde pra frente, mas lembre-se de documentar.
> Primeiro, porque nós mesmos precisamos entender o esquema utilizado e
> depois porque sem uma boa documentação ninguém irá chegar a aproveitar
> desta flexibilização.
>

> Em 02/12/07, Riceman<andrerflori...@hotmail.com> escreveu:

[Passarin Jr.]

Taí, buli concordo em "número, gênero e grau" com você. O nosso foco
principal por enquanto tem que ser o Painel em si, deixá-lo mais
completo que o próprio clica-aki. Não me importo em colocar vários
comandos "shell" dentro do código do gambas, na minha concepção na
verdade tudo deveria ser feito via Gambas eliminando inclusive (e
quando possível) até mesmo os "x-dialog da vida" ou radicalizando
ainda mais, até mesmo os "x-terms". Mas isto também pode esperar...
É bom lembrá-los que estou trabalhando na versão 2.0 do nosso Painel,
que trará muitas novidades devido às novas ferramentas ofecidas pelo
Gambas2. O único porém é que o Gambas2 ainda está instável e talvez
por isso o apt-get desinstala alguns programas importantes ao instala-
lo. Por isso gostaria que ainda na série 1.7 o Clica-ai esteja
completo.
Abraços!
.

On 6 Dez, 00:45, buli <troes...@gmail.com> wrote:
> Os dois tipos de tarefas dariam um trabalho danado.
>
> Acho que na abordagem de Passarim, para portar o painel primeiro
> teriamos que portar todo o Kurumin 7, ou grande parte dele, e depois o
> painel acompanharia como "bonus", por assim dizer. Não é uma coisa
> ruim, pelo contrário, como já disse no meu último post, mas acho que
> requere um equipe "multidisciplinar", com mais pessoas.
>
> Até não reunir interessados que possam ajudar no K7, acho que a gente
> teria que se focalizar no painel em sim mesmo:
>
> Prioridade 1: Deixar ele completamente funcional no K7, e fazer
> "publicidade" para os usuários migrarem do clica-aki para oclica-ai.
> Desde que eu me recordo, o Morimoto está sempre dizendo, em sites ou
> entrevistas, que ele não tempo para o Kurumin, mas o projeto de alguma
> maneira continua.
>
> Prioridade 2: O "novo" painel configurável. Parece-me que ele teria
> ser quase reconstruido de zero, mas esso pode ir sendo feito aos
> poucos. O fato do Kurumin estar em risco de continunidade acho um
> incentivo a mais para se concentrar no painel e não na plataforma.
>

> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------

[Riceman]

Olá, pessoal!

Primeiramente um Feliz Ano Novo pra vocês. Desculpem minha ausência,
estive muito ocupado no trabalho nos últimos dias do ano passado e
depois viagei para locais sem conexão (praia, maravilha!)

Mas vamos ao que importa. Buli, também concordo com suas sugestões.
Você poderia postar estes scripts que você mencionou para eu ir
bolando alguma coisa?

A não ser que o Passarín queira desenhar as interfaces gráficas, já
que ele está criando-as, para manter um mesmo padrão visual (do mesmo
criador). Para mim tanto faz!

Grande Abraço,

Riceman

[Airton Santana]

 fala irmão! Feliz ano novo pra você e pro buli também!
 Já tava com saudades de vcs! rsss! Também andei atarefado e tô voltando  a trabalhar no painel só agora...tenho alguma coisa da versão 2.0 do nosso Painel que estou desenvolvendo usando o gambas2, que já está em RC.
 Vou postar no grupo ainda hoje. Não praticamente nada codificado...assim que eu postar dou mais detalhes..
 Abração a todos!

Em 02/01/08, Riceman < andrerf...@hotmail.com> escreveu:

[Passarin Jr.]

Mudança de planos. Devido ao Projeto "Kurumin 8", vamos concentrar o
desenvolvimento na versão 2.0 do nosso painel, pois ele virá com
muitas melhorias em relação à versão atual.
Quando tivermos tudo pronto voltamos à questão da portabilidade. Creio
que "desmembrar" alguns mini-aplicativos pode ser viável...
Gostaria também de saber a opinião de vcs sobre o projeto "Kurumin
8" (vide forum GDH). Pedi pra que vcs sejam incluidos neste grupo
também.
abraços!