Nerd, programador, desenvolvedor e usuário de Software Livre, grafista digital, vegano, ciclista... Adoro a expressão "Free as in Freedom".
Shell Script e Ícones Dinâmicos na Área de Notificação
November 19, 2009, by Aurélio A. Heckert - 9 commentsOk, você já sabe como fazer um Shell Script. Você até se sente feliz com aquela saída textual... Você precisa voltar ao terminal toda vez que quer saber do status daquele script mais demorado, mas isso não é um problema. Isso não é chato, mas... mas e se seu script pudesse representar informações graficamente? E se seu script pudesse apresentar essa informação na área de notificação? Ah... seria massa!
Mas se você está acostumado a escrever Shell Scripts, então você já leu sobre Zenity ou já usou essa ferramenta em algum momento. Com Zenity podemos adicionar interfaces gráficas simples a Shell Scripts e torna-las virtualmente independentes da interface textual do terminal (claro... com outras limitações). E é a Zenity quem vai colocar nossas informações gráficas na área de notificação, seja GNOME, KDE, XFCE ou outro gerenciador de desktop que implemente a área de notificação padrão.
Você não sabe o que é Zenity? Garanto que vai gostar de saber o que ela pode fazer por você. Para dar uma lida na ajuda da Zenity, execute o comando:
$ zenity --help
Faça isso, eu espero aqui.
Não vou tratar das possibilidades e detalhes da Zenity agora, então, vamos seguir adiante. Tente o seguinte: 
$ zenity --notification --listen
Notou que apareceu um ícone de alerta na área de notificação? Podemos muda-lo. O argumento --listen faz com que a Zenity, no modo notificação, fique na espera de comandos na entrada padrão. Então agora escreva: 
icon:/usr/share/icons/gnome/scalable/emotes/face-smile.svg
icon é um dos comandos aceitos para modificar a notificação e como argumento espera o caminho para uma imagem qualquer, seja jpg, png, svg ou outros formatos suportados pela GTK. Eu prefiro trabalhar com SVG para manter a independência da resolução, já que o tamanho da área de notificação é definido pelo usuário.
Já vimos como colocar ícones na área de notificação e como modifica-los. Vamos ver o mais interessante: Como criar ícones com Shell Script para, então, apresenta-los.
Podemos criar imagens “do nada” ou manipular imagens existentes para apresentar suas derivações. Os caminhos mais interessantes para criação (na minha perspectiva) seriam:
- Escrever um SVG;
- Usar o ImageMagick;
- Escrever um arquivo XPM.
O código SVG é um XML, portanto, para um SVG simples, qualquer método para criar automaticamente um arquivo de texto é suficiente: Nesse exemplo criamos um ícone informando o dia da semana e quanto dela já passou: 
echo "<svg width='30' height='30'>
<rect x='0' y='0' width='30' height='30' fill='#46A' />
<rect x='0' y='$(( 30 - ( $(date +%u)*30 / 7 ) ))'
width='30' height='$(( $(date +%u)*30 / 7 ))' fill='#09E' />
<text x='15' y='20' fill='#FFF'
style='font-size:12px; font-family:sans-serif; font-weight:bold;
letter-spacing:-1; text-anchor:middle; text-align:center'>
$(date +%a)</text>
</svg>" > /tmp/dia-da-semana.svg
zenity --notification --window-icon=/tmp/dia-da-semana.svg
Sim, o parâmetro --window-icon já predefine o ícone da notificação. É suficiente para o exemplo.
Criar imagens com ImageMagick é interessante, mas não vai dar tempo. Vamos deixar essa para outro dia...
Escrever um arquivo XPM? Isso é pré-histórico! Mas ainda é uma forma interessante de criar pequenos bitmaps na boa perspectiva do pixel-art. Veja aí um exemplo de conteúdo de um arquivo XPM: 
/* XPM */
static char * sorriso_xpm[] = {
"20 20 2 1",
" c None",
"# c black",
" ",
" ",
" ",
" ",
" ",
" ## ## ",
" ## ## ",
" ## ## ",
" ## ## ",
" ## ## ",
" # # ",
" # # ",
" ## ## ",
" ### ### ",
" ########## ",
" ######## ",
" ",
" ",
" ",
" "};
Da mesma forma que parametrizamos a criação do SVG, podemos parametrizar a criação do XPM, redefinindo cores e pixels pintados. Use a imaginação e divirta-se!
Os caminhos mais interessantes para derivação de uma imagem, seriam:
- Transcrever código SVG com sed;
- Modificar um SVG com XMLStarlet;
- Manipular bitmaps (png, jpg...) com ImageMagick.
Não vai dar para falar do XMLStarlet e do ImageMagick agora, vamos aproveitar para criar uma aplicação mais próxima do mundo real com o sed como a grande estrela. Que tal um gráfico dinâmico mostrando quanto do processador é usado pela aplicação que mais o ocupa? Vamos lá... 
#!/bin/bash
tmp_dir=$( mktemp -d )
echo '<svg width="30" height="30">
<defs>
<marker id="bola" refX="0.0" refY="0.0" style="overflow:visible">
<circle cx="0" cy="0" r="1.5" fill="#048" />
</marker>
</defs>
<rect x="0" y="0" ry="5" width="30" height="30" fill="#69B" />
<path d="M 0,20 L 5,19 L 10,18 L 15,17 L 20,16 L 25,15 L 30,14"
style="marker-start:url(#bola); marker-end:url(#bola);
marker-mid:url(#bola); stroke:#259; stroke-width:2; fill:none" />
</svg>' > $tmp_dir/orig.svg
v[0]=300; v[1]=300; v[2]=300; v[3]=300; v[4]=300; v[5]=300; v[6]=300
while true; do
# pega dados do processo com maior uso do processador:
prog=" $( top -b -n1 | head -n8 | tail -n1 )"
# pega o uso do processador e nome do processo que mais o ocupa:
prog_proc=$( echo $prog | cut -d' ' -f9 )
prog_nome=$( echo $prog | cut -d' ' -f12 )
for i in 0 1 2 3 4 5; do v[$i]=${v[$(($i+1))]}; done
v[6]=$( echo "30 - ( ($prog_proc/90) * 30 )" | bc -l )
d="M 0,${v[0]} L 5,${v[1]} L 10,${v[2]} L 15,${v[3]}"
d="$d L 20,${v[4]} L 25,${v[5]} L 30,${v[6]}"
sed -r "s/ d=\".*\"/ d='$d'/" $tmp_dir/orig.svg > $tmp_dir/ico.svg
echo "tooltip:$prog_nome ocupa $prog_proc% do processador"
echo "icon:$tmp_dir/ico.svg"
sleep 2
done |
zenity --notification --listen
rm -r $tmp_dir
Sim, o SVG não precisava ser criado pelo script, isso foi feito apenas para não separar o exemplo, mas também pode ser útil em um script para o mundo real, caso não seja muito complexo. O sed, quem atualiza o ícone, apenas substitui o atributo d, que ocorre apenas uma vez no SVG do exemplo. Depois de gerar o ícone, informamos à Zenity para que o recarregue e ainda atualizamos o tooltip para que o usuário tenha acesso a mais informações caso tenha interesse.
Bom, não tenho mais tempo, podemos aprofundar os assuntos que apenas foram citados em outra oportunidade, mas quais? Vou esperar pelos pedidos...
GIMP Oficialmente em uma Janela
October 9, 2009, by Aurélio A. Heckert - No comments yetTalvez esse seja o maior e mais antigo desejo da comunidade de usuários GIMP. No último LGM Peter Sikking mostrou como a comunidade tem proposto novas interfaces fortemente alinhadas com o modo single window em gimp-brainstorm.blogspot.com.
Na real a comunidade já havia tentado de forma independente fazer isso por vários meios. Já foram criados plugins e ferramentas externas já foram usadas, mas a que mais me chamou a atenção foi o uso de Xnest para que todo o GIMP fique em apenas uma janela do ambiente principal.
Pois bem, finalmente um cara legal (Martin Nordholts) começou a implementação do modo single window e já está disponível no repositório GIT onde está o código oficial do GIMP. Se você sabe o que significa compilar um software, já pode testar a nova interface, mas lembre-se que ela ainda está em desenvolvimento.
As pessoas que gostam de múltiplas janelas ou as que vêem utilidades em alguns usos de múltiplas janelas (como eu), ainda poderão trocar de modo ou usar soluções intermediárias, como fazemos com o Inkscape.
.Net e as Patentes Esquecidas
October 3, 2009, by Aurélio A. Heckert - 4 commentsNo post ".Net e o open source" nosso colega Rodrigo fez uma importante apresentação do discurso da Microsoft sobre o conflito acalmando entre o Mono e as patentes da MS. É importante dizer isso, pois alguns leitores talvez não conheçam o caso, mas é importante deixar claro: A MS não disse tudo.
A pregunta base nesse texto é: De que vale a patente se a MS não pretende usa-la? É só para fazer coleção?
Relacione isso com os EUA, o dono do maior arsenal atômico do mundo (faço essa analogia porque existe uma gerra fria na industria de TI — FLOSS está incluso — e as patentes são a maior arma). Quando vamos para o Software Livre, vamos para um país fora do alcance dos misseis norte americanos (como se fosse possível...), ou ao menos para onde o efeito deles é menor. Usar .NET, Mono no caso, é ir para perto e ter um míssil apontado para você. Sua única garantia é a promessa dele de não atirar em você.
Mas eu volto a perguntar: de que vale a patente se a MS não pretende usa-la? Acho que é muita bondade achar que a carta de compromisso realmente valerá para sempre ou para qualquer caso. É comum aos de boa vontade presumir honestidade a quem não merece e tem histórico para não merecer.
Não precisamos relembrar de tudo que a MS fez e o que falam seus membros, não é mesmo? Então vamos só avaliar uma condição inerente as empresas S.A.: <ATENÇÂO> isso não é um texto anarquista ou socialista, é uma analise lógica </ATENÇÂO> Quando uma empresa abre seu capital (torna-se S.A.) ela perde o pouco de moral e ética que tinha por reflexo do dono (ou pequeno grupo de donos). Uma S.A. não representa absolutamente nada mais do que um número na bolsa de valores e é o capital especulativo uma das maiores influências nas suas atitudes. Se ela gerar menos lucro seus papeis são vendidos, seu valor cai e ela sofre duas vezes. É obrigação dela fazer seus papeis valerem e realmente é sua principal preocupação. Desde que a maioria não se sinta mal com uma atitude da empresa, ela pode toma-la e pode fazer mal a quem quer que seja em prol do lucro e valorização dos papeis. A ética está totalmente morta nesse ponto e seu único limite é a lei. (Não entendeu ou não levou a sério, veja os dados no documentário The Corporation)
Sendo assim, o que a impede de dizer "não foi bem isso que eu disse no documento..." e pronto, você está na mira.
Stallman disse:
"don't depend on C#, because Microsoft may set its patent lawyers on you someday. Does that strike you as radical? To tell people to watch out for patents? Your lawyer would tell you no different."
Até agora o que disse foram suposições (sóbrias) sobre um futuro infeliz na popularização do Mono, caso a MS tenha mais uma atitude anti-ética. Mas há mais com que se preocupar: A promessa da MS engloba apenas o ECMA-334 e ECMA-335, porem o Mono tem muitas peças fora do ECMA e sob patente da MS (como ASP.Net e ADO.Net). Se até o paragrafo anterior você não tinha se preocupado, preocupe-se.
Quem acredita no que diz a MS ou qualquer outra S.A. erra como quem acredita em notícias da guerra. Erra como quem acreditou nos "mísseis cirúrgicos" dos EUA ou nos seus motivos para atacar o Iraque.
Note que não corrigi Rodrigo até o momento, porque ele replicou corretamente o discurso da MS eu mostrei o buraco no discurso dela, mas, em prol da boa informação, faço uma pequena correção na frase de seu post que diz: "O Debian incluiu o Mono como seu principal meio de instalar o GNOME por razões do Tomboy...". O Debian (quase) sempre é citado quando queremos reforçar o quanto algo é próximo da liberdade, pela seriedade e independência deste projeto, mas na realidade o Mono não é dependência do GNOME no Debian. O Debian recomenda o Tomboy para o pacote GNOME, que por sua vez traria o Mono, mas o pacote GNOME não depende dele e portanto instalar GNOME no Debian, por padrão, não instala Mono. E ter dito que o Mono é o principal meio de instalar o GNOME é um tanto exagerado :-) ... é até um certo desrespeito ao projeto GNOME que não aceitou colocar Mono em sua infraestrutura.
Concluindo... De qualquer forma, mesmo se pudermos confiar em uma mudança de postura da MS (hã!?) temos que levar a sério a garantia de nossa liberdade e patentes são as únicas armas mais fortes que o licenciamento livre. Se uma empresa diz apoiar um projeto e ao mesmo tempo deixa claro que tem patentes sobre ele, afaste-se. Não perdemos nada! Existem tantas outras ferramentas... Permitir que esse modelo dê certo é um enorme risco a tudo o que construímos até hoje. É preciso combater o patenteamento de software e não buscar um tratado de paz, assim como com as armas nucleares.
...e fica cada vez mais ridículo fazer sites apenas para IE
August 6, 2009, by Aurélio A. Heckert - No comments yetDeveria ser suficiente falar em direito de escolha e padrões da web para fazer com que (pseudo) webdesiners e grandes instituições (o que inclui bancos e governos) não fizessem sites "Best viewed with MSIE".
O bom site não pode obrigar que o usuário use um navegador ou outro. Deve estar pronto para a forma de acesso escolhida pelo visitante. Limitar visitação ao MSIE é um claro desrespeito a diversidade. Me parece inaceitável ver uma atitude dessas em um banco (gênero de instituição que vincula sua imagem a tipos variados de pessoas felizes) ou em um orgão governamental (entidade que deveria trabalhar pelo bem da sociedade considerando as diferenças entre seus indivíduos).
Pois bem, já passou o tempo em que fazer sites com olhos apenas no MSIE refletia apenas desrespeito, agora, com o crescimento dos outros navegadores, já beira ao ridículo desconsiderar quase 1/3 dos usuários da web.

Browser Marketshare de julho de 2009, pela Net Applications
Você, cara bem intensionado, pode usar isso como agrgumento caso seu chefe não entenda o que está fazendo. (Tente... garanto que vale a pena!)
Como é possível viver de Software Livre?
July 21, 2009, by Aurélio A. Heckert - No comments yetUm rapaz chamado John me mandou um e-mail fazendo aquela pergunta que todo cara que divulga SL já ouviu: "Como é possível viver de Software Livre?"
O interesse dele é em jogos, então vou tentar responder de forma generalista e depois trato dos jogos.
Gostei da pergunta do John, porque ele perguntou "Como é possível?" e não "É possível?". Ele já sabe e agora quer o caminho das pedras, mas... Não existe caminho das pedras. Ou melhor, não existe um caminho das pedras. 
Eu sou sócio da Colivre, essa empresa cooperativa (é chato ter que lembrar isso, mas as pessoas não fixam a idéia que a cooperativa é uma empresa, justa e com princípios, mas é uma empresa) foi criada com amigos do tempo da faculdade que tinham sonhos em comum: Ter uma relação de trabalho mais justa e trabalhar com Software Livre.
Na Colivre usamos Softwares Livres como o Papers, o Inkscape e o Foswiki para prestar serviços e colaboramos com esses projetos em retribuição (por conta da nossa relação com o SL) e em prol da melhoria dos nossos serviços.
Alem de usar e colaborar, também criamos Softwares Livres quando temos demanda por isso. Nosso melhor exemplo é o Noosfero, licenciado sob AGPLv3, assim como tudo o que criamos está sob uma licença livre.
Nosso software não é produto de caixinha,
é fruto de serviço.
Assim é fácil faze-lo livre.
Tendo isso em mente vemos que a maioria, se não todas, as software houses brasileiras poderiam produzir Software Livre ou, o que seria melhor, usar um SL como base e melhora-lo para responder a demanda e beneficiar toda a sociedade. Por quê? Porque a maioria, se não todas, escrevem software como serviço a demandas (aparentemente) específicas. Sim, "aparentemente específicas" porque se assim fossem realmente a base de código não seria tão útil para reuso (e como reusam...) e não haveria porque se especializar em responder as necessidades de nixos.
Sendo assim, uma forma de viver de Software Livre seria a velha prestação de serviços, com o adendo da licença livre no contrato.
Mas a licença livre não espanta clientes? Para a Colivre foi justamente o contrário. Muitas pessoas com poder de decisão se importam com os benefícios (incluindo sim os sociáis) que o Software Livre traz e por isso nos procuraram.
E de que outras formas podemos viver com Software Livre?
Participando de Fundações ou ONGs voltadas para o movimento de Software Livre, como a Fundação GNOME, a Fundação Mozilla e a Fundação Software Livre - América Latina. Ou participando de ONGs bastante próximas do movimento ou que tenham o Software Livre no seu estatuto, como a Safernet Brasil
Organizando consórcios empresariais para promover projetos. Claro que aqui você precisa de uma pessoa com contatos e respeito no meio empresarial.
Buscando editais. Governos estaduais e o federal lançam frequentemente editais que podem ser executados com Software Livre. Mas é preciso paciência e estomago... você sabe como são as coisas...
Existem 1000 maneiras de se preparar Neston®. Invente uma!™
E quanto aos jogos?
É possivel constrir jogos com Software Livre, usando as diversas engines disponíveis, como a clássica Allegro, a DarkPlaces (derivada do Quake) e o Blender com Crystal Space (veja um tutorial) e nada (até o momento) ilustra melhor que YoFrankie
Como ganhar dinheiro (suficiente para o sustento) com eles é uma icognita para mim, porque não me interesso por esse mercado e não ouvi falar de nenhuma experiencia do gênero. Então vou tratar sobre os problemas, porque é daí que surgem as oportunidades.
Divagação introdutória: Por que eu colaboro com o Inkscape? Porque eu uso ele quase todos os dias e depois de conhece-lo bem, passei a estudar como melhora-lo e só então passei a faze-lo. Em geral é preciso envolvimento constante de um programador com um projeto para que ele começe a colaborar com ele, por isso projetos de uso diário tendem a ter um crescimento continuo no número de desenvolvedores (o que deve levar a estabilização e reciclagem continua). Estou falando sobre comunidade porque não dá para pensar na sustentabilidade de projetos livres sem comunidade e sem sustentabilidade também é difícil garantir o sustento financeiro.
Como acontece com jogos? É de se esperar que o usuário jogue até zerar, se o jogo for bom ele joga mais algumas vezes como passa-tempo e depois se esquece que o jogo existiu. Desta forma ele não cria vínculo e não aparece o interesse em colaborar. Isso explica porque o time de desenvolvedores de projetos de jogos inicia um número pequeno de pessoas, pode agregar um ou outro pela proposta, mas definha e morre com a saída dos desenvolvedores, um a um, para outros projetos.
Os jogos que parecem escapar desse processo são os RPGs massivos on-line, como o Mana World, onde o usuário tem um forte argumento para retornar ao jogo: relacionamento social. Este é um caso muito especial que tem forte potencial para modelos econômicos muito próprios, então fica para divagação pessoal porque não volto para esse caso.
Os jogos livres tem muito potencial, mas costumam sofrer com a falta de arte e roteiro, o que faz toda a diferença. E a explicação provável (não existe pesquisa é só vivencia) é o fato de que são feitos por programadores e quando temos alguém focado na arte é o cara que está aprendendo a usar Blender (na verdade aprendendo modelagem 3D, o que é pior). Mas vc não citou o roteirista... porque não tem. E não adianta lançar o jogo assim e esperar que o envolvimento com a comunidade o melhore, pois não vai acontecer com a força que acontece para uma ferramenta usada no dia-a-dia.
Para fazer um bom jogo precisamos de um investimento pesado no inicio, no planejamento. Isso explica porque o Bos Wars saiu legal, ele foi criado pela equipe do Stratagus, que já sabia um pouco mais sobre "como fazer". O mesmo parecia que iria acontecer com o Super Tux 2, que foi melhor planejado (ou melhor recebeu algum planejamento), mas nunca foi lançado.
Isso não quer dizer que jogos não se encaixem no modelo livre, é muita falta de visão entender assim, mas os jogos não podem ser criados como os desenvolvedores gostam, codifica primeiro e pergunta depois. 
Bom, se é difícil manter uma comunidade de usuários ao redor de um jogo, então também será difícil fazer com que esse jogo livre gere renda. Mas temos como...
Claro que podem existir outras formas, mas eu só pensei em usa-lo como peça de marketing. Divulgação de Marcas: uma empresa quer ser mais comentada, ela pode ser representada dentro do jogo e fortemente divulgada como financiadora do desenvolvimento. Divulgação de Idéias: uma ONG ou um governo quer mostrar que uma atitude é melhor que outra. O roteiro de um jogo ou as regras do jogo podem focar na questão e fazer o usuário vivenciar e aprender jogando.
Como disse antes, o caso dos jogos não me interessa, mas fica aí a dica de um caminho que me parece viável. No fim das contas o que se exige de você é criatividade. 












