Feed RSS Nerd, programador, desenvolvedor e usuário de Software Livre, grafista digital, vegano, ciclista... Adoro a expressão "Free as in Freedom".


meu man é mais bonito que o seu

January 4, 2010, by Aurélio A. Heckert - One comment

man most coloridoman wget colorido

Gostou? Achei essa dica por acaso no dicas-l.

Se você usa Debian, Ubuntu ou derivado, basta executar essa linha:
$ sudo apt-get install most && sudo update-alternatives --set pager /usr/bin/most

"most" é um comando equivalente a "less" e "more" mas é capaz de outras coisinhas interessantes, como dar cores a certos comandos de formatação.

O "update-alternatives" é usado para atualizar e manter a configuração que define o most como paginador, no lugar do less.

Registrei essa linha no commandlinefu.  :-)



10 Problemas com o Novo Pacto Moonlight

December 23, 2009, by Aurélio A. Heckert - No comments yet

Dois meses atrás eu falei sobre o o risco que o .Net representa para o software livre e a independencia tecnológica de modo geral no post ".Net e as Patentes Esquecidas".

Hoje, o site The Source publicou o artigo "10 Problems with the New Moonlight Covenant", de Jason Melton, mostrando que devemos redobrar a atenção para esse problema. O artigo tem um pouco mais de informação, mas o principal (a lista), repasso a tradução:

Problema #1: Somente Novell, Parte 1

De acordo com o termo definido Conformação de Host, somente a Novell pode criar "lançadores" para aplicações não-browser. Você não é a Novell? Você não pode implementá-lo.

 

Problema #2: Sem desvios

Além disso, aplicações shell são bastante limitadas. Novamente, de acordo com os termos definidos, aplicações shell não podem:

  1. Fazer qualquer coisa que um plug-in de navegador web não seja capaz.
  2. Fazer algo a mais ou a menos do que o Silverlight pode fazer.
  3. Impedir qualquer coisa que um plug-in de navegador web possa fazer.

 

Problema #3: Limitações de SO

Atuais e futuras versões do Windows e Mac são expressamente excluídos da definição de cobertura de Sistemas Operacionais. Sim, você leu certo. Moonlight não pode ser multi-plataforma.

 

Problema #4: The Killswitch (botão de desligar)

A Microsoft pode modificar ou suspender o pacto a qualquer momento. Claro, o que for distribuido antes da mudança/cancelamento estará "seguro", mas será um problema para futuras versões.

 

Problema #5: Sobreposição de Promessas

Microsoft afirma explicitamente que nenhuma outra licença, pacto, comunicado ou outro direito será concedido, mesmo que seja relacionado ou que se permita. Isto significa que todas as tecnologias no âmbito do chamado Microsoft Open Specification Promis ou Microsoft Community Promise, não podem ser abrangidas por ambos os conjuntos de promessas/pactos.

 

Problema #6: Somente Novell, Parte 2

As definições do "Moonlight" e as partes abrangidas claramente só se aplicam a "essas partes desenvolvidas por ou em nome da Novell".

 

Problema #7: Somente Novell, Parte 3

Os pacotes de mídia são cobertos apenas se você usar cópias do Moonlight providas pela Novell.

 

Problema #8: Plataforma Limitada

Apenas computadores pessoais estão cobertos. O pacto exclui explicitamente "assistentes digitais pessoais (PDAs), Pocket PCs, reprodutores de mídia pessoais (PMPs), ou telefones móveis".

 

Problema #9: Hostil à GPL

O "Pacto" da Microsoft é especificamente hostil à GPLv3. Você não está coberto se alguma parte está sob uma licença GPLv3 ou similares, mesmo que todas as outras qualificações sejam cumpridas. O simples ato de escolher uma licença GPLv3 ou similar é suficiente para anular o pacto.

 

Problema #10: Data de Expiração

Não só o pacto acaba em 31 de dezembro de 2012 (que pode ser prorrogado ou encerrado antes), mas pacto só se aplica durante o prazo. Ou seja, se o software está coberto em 30 de dezembro de 2012 e o pacto não foi prorrogado, então esse mesmo software já não é coberto em 1 de janeiro de 2013, mesmo se o uso anterior foi coberto.

Como você pode perceber, se opor ao .Net e ao Mono não é uma atitude meramente anti-Microsoft, é uma defesa consciente da liberdade e da independência tecnológica.

Em tempo: ser independente não é estar ilhado, é ter autonomia para tomar suas decisões, coisa que um usuário ou desenvolvedor de .Net perder quando a MS achar conveniente.



Saída CMYK no Inkscape a caminho

December 8, 2009, by Aurélio A. Heckert - 2 comments

Inkscape CMYK

Alguns membros da comunidade brasileira do Inkscape (específicamente eu, Farid, Jonata Bolzan e Cezar Farias) formularam uma especificação para desenvolvimento do suporte a CMYK no Inkscape, que já começou a ser implementada por nosso amigo Felipe Sanches, o Juca.

O Inkscape já tinha o seletor CMYK desde sua criação e o suporte a perfis de cores foi completado com ajuda de Juca para a versão 0.47, mas o Inkscape ainda registrava apenas valores RGB no SVG e não gera saídas em CMYK. Na versão de desenvolvimento, nos repositórios do projeto, já temos o Inkscape registrando valores CMYK no arquivo SVG e esperamos ter uma saída neste espaço de cor para gráficas na versão 0.48.

Quer ajudar o Juca a realizar esse trabalho? Quer agradece-lo por tudo o que ele já fez? Envie a quantidade que quiser ou puder para a conta dele.



Inkscape 0.47, depois de MUITO trabalho, chegou!

November 26, 2009, by Aurélio A. Heckert - 2 comments

Depois de mais de um ano de muito trabalho e um necessário atraso no lançamento, acaba de sair o Inkscape 0.47!

Inkscape 0.47 Mugg Veja as principais melhorias desta versão:

  • Salvamento automático Temporizado: o fim do trabalho perdido
  • Spiro splines: uma nova e excitante forma de trabalhar com caminhos, totalmente fumcional no lápis, caneta e editor de nós
  • Auto suavização de nós: um novo tipo de nó que mantém o caminho o mais suave possível enquanto você move seus vizinhos
  • Novos modos na ferramenta Ajustador: empurrando e modelando objetos inteiros, redimensionando/rotacionando objetos, deletando e duplicando usando o "pincel macio"
  • Sistema de alinhamento e barra de configuração de alinhamento, refeitos e muito mais usáveis
  • Novos efeitos em caminhos, incluindo sketch, hatching, envelope; Efeitos podem ser empilhados e aplicados a grupos
  • Uma grande coleção de filtros pré-definidos no novo menu Filtros
  • Nova exportação para PS e EPS baseada em Cairo: melhor qualidade, suporte a mais funcionalidades, resterização para filros e transparência
  • Corretor ortográfico para textos no documento
  • Muitas extensões novas: restacking, calendário, marcas de impressão, grades cartesiana e polar, interpolação de atributos
  • Opções de otimização de código SVG, agora com sua própria página de preferências
  • Muitas outras melhorias, ajustes de usabilidade, correção no vazamento de memória, e vários bugs corrigidos

3 das minhas extensões aparecem nessa lista das principais melhorias! Essa lista só não está melhor porque não cita o suporte a fontes SVG do Juca, mas veja a lista completa abaixo, para conhecer todos os detalhes e ver a referência às fontes SVG:



Shell Script e Ícones Dinâmicos na Área de Notificação

November 19, 2009, by Aurélio A. Heckert - 10 comments

Ok, 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:

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...