Passando o chapéu: Suporte o KDE Randa Sprint 2012

Post replicado de http://blog.filipesaraiva.info/?p=873

O KDE está buscando recursos financeiros para viabilizar o KDE Randa Sprint 2012, reunião de desenvolvedores que objetiva avançar em alguns importantes projetos-chave para o futuro do KDE.

Click here to lend your support to: KDE Randa Meetings and make a donation at www.pledgie.com !

Se o KDE é importante para você, e se estiver ao seu alcance, considere fazer uma doação para viabilizar esta reunião! =)

O texto abaixo é uma tradução do texto no dot KDE onde é apresentado a proposta, a importância, e quais principais objetivos os devs que irão ao KDE Randa Sprint 2012 almejam atingir.

Suporte o KDE Randa Sprint 2012: Inspirador e Intenso
por Carl Simon, traduzido por KDE Brasil

Os encontros KDE Randa Sprint são um pequeno encontro de contribuidores do KDE na vila de Randa, Suíça. Em seu quarto ano, o Randa sprint incluirá projetos chaves do KDE e importantes desenvolvedores, todos colaborando simultaneamente sob o mesmo teto, isolados do barulho e distração. Estamos pedindo um auxílio financeiro para dar suporte ao encontro.

“Os sprints em Randa são especiais. Envolvidos por uma paisagem montanhosa, uma intensa colaboração acontece, com todo mundo reunido em um único lugar. Encontrar-se lá significa trabalho feito e sem fuga de planejamento, apenas discutindo e programando.” disse o duas vezes participante de Randa e hacker de Acessibilidade no KDE, Frederik Gladhorn.

Estratégia, planejamento e coordenação. photo by Kévin Ottens

Randa 2012 acontecerá de 21 à 27 de Setembro de 2012. Os participantes do encontro tem metas ambiciosas que irão beneficiar usuários e desenvolvedores do KDE.

  • O time de Acessibilidade no KDE e especialistas em Acessibilidade do GNOME vão facilitar o uso de aplicações acessíveis, particularmente para pessoas com deficiência visual. Cegos e pessoas com baixa visão foram convidadas para providenciar orientação e assistências durante os testes.
  • Desenvolvedores do KDE-Edu estarão trabalhando nas aplicações educacionais existentes e em novas, especialmente para dispositivos móveis.
  • O  times de Multimidia do KDE e do Amarok irão discutir o futuro do Amarok, particularmente em dispositívos móveis. Além disso, eles irão trabalhar com o Framework de Multimidia Phonon do Qt5, o qual é a fundação das aplicações de som do KDE.
  • Planejamento para o futuro dos Plasma Workspaces, particularmente como eles se relacionarão com o KDE Frameworks 5, baseado no Qt 5. Esse trabalho é crítico para definir uma direção comum e necessário para mudança a um ambiente de desenvolvimento atualizado com perturbação mínima para os usuários. O time também fará um intenso trabalho de escrita de código.

Mão na massa! photo by Anne-Marie Mahfouf

Todas as reuniões prévias em Randa foram focadas e produtivas, gerando resultados excepcionais; organizadores e participantes esperam o mesmo e até mais para esse ano. As reuniões em Randa produziram significantes avanços no passado, tais como:

  • Aplicações do KDE e ambiente Plasma rodando em CPUs ARM,
  • Um framework de autorização segura,
  • Projeto do KDE Frameworks como um substituto para kdelibs e KDE Platform, melhorando o relacionamento com o upstream e simplicando dramaticamente o desenvolvimento.
  • Documentação de usuário completa e eliminação de bugs no Amarok.
  • O time de Multimidia do KDE otimizou as aplicações e o framework de desenvolvimento para melhorar a performance e simplificar o seu uso.

Esse ano, 35 desenvolvedores de todo mundo (sendo que 3 deles são aqui do Brasil), irão para o encontro em Randa. Em sete dias inspiradores cheios de trabalho, eles irão realizar mais do que eles mesmos imaginam, guiados pelo compromisso de apoiar o software livre para todas as pessoas.

Enquanto os participantes são voluntários não remunerados, existem grandes despesas, tais como acomodações, comida e transporte. Se você não vai comparecer, você ainda pode apoiar o encontro em Randa através de uma doação. Como já aconteceu antes, o encontro em Randa irá beneficiar todos que usam o software do KDE.

A arrecadação de fundos tem como meta 10.000€. Por favor, doe o que você puder  para ajudar a tornar possível KDE Randa Sprint 2012

Removendo o uso de ponteiro de ponteiro de funções

O uso de ponteiros de ponteiros é uma forma de armazenar estrutura bidimensionais (uma matriz por exemplo) ou quando se deseja atualizar o valor de um ponteiro.
O primeiro caso, é uma ótima forma de representar estruturas bidimensionais, mas o segundo caso deve ser evitado.
Por que evitar o segundo caso? Você terá que se preocupar com acesso ao conteudo usando o operador *, isso deixará seu código menos legível, uma vez que você poderá ter que usar parenteses para indicar a precedência do operador * sobre o operador ->, um código eu seria algo como ptr->k = ptr->k+10 passa a ser (*ptr)->k = (*ptr)->k+10.
Essa falta de legibilidade trás também uma complexidade e pode trazer também confusão, uma vez que você passa a trabalhar com um apontardor para um apontador de onde está a sua estrutura.
Essa forma de acesso indireto é mais lenta que o acesso direto, uma vez que será necessário primeiro descobrir o endereço onde está o ponteiro, depois com esse endereço acessar a estrutura no endereço indicado pelo ponteiro.
Uma forma bastente utilizada do ponteiro de ponteiro é o seguinte
{    …
  MeuTipo * ptr = NULL;
  criaTipo(&ptr)
    …
}
e a função que recebe o endereço do ponteiro:
void criaTipo(MeuTipo ** pdp){    …
  (*pdp) =  (MeuTipo*) malloc ….;
    … inicializa dados em pdp usando (*pdp)
}
O que esse trecho de código faz é uma inicialização de um ponteiro, mas você pode considerar que ptr não apontava para NULL mas para o início de sua lista ligada ou para a raiz de sua árvore enraizada e a função criaTipo irá incluir um novo elemento na sua árvore ou lista (o que pode mudar o apontador).
Temos 3 pontos básicos: Primeiro a chamada da função criaTipo que recebe como parâmetro o endereço do ponteiro ptr (operador &). Veja que ele possui um valor nulo, mas ainda assim possui um endereço válido, uma vez que um ponteiro é uma variável (que armazena endereços de memória) e esse ponteiro está em algum lugar da memória.
Segundo ponto é a inicialização de um espaço de memória (o malloc) que será armazenado no ponteiro que teve seu endereço passado como parâmetro (nessa caso o endereço para o qual ptr apontava é substituido pelo endereço alocado).
O terceiro ponto que é a inicialização dos valores da estrutura (pode ser apontar prox para null) que deve ser feito usando o acesso ao conteudo do ponteiro de ponteiro (*pdp).
Podemos modificar o código para que não seja mais necessário passar o ponteiro de ponteiro (e com isso tornar mais legível o código). Primeiro vamos mudar a função criaTipo trocando o parâmetro de ponteiro de ponteiro para um ponteiro simples e mudando o seu retorno também.
MeuTipo * criaTipo(MeuTipo * pdp) {
    ….
Com essa alteração, é esperado o seguinte comportamento:
Se houve a necessidade de alterer o valor para o qual o ponteiro original apontava, esse novo valor deve ser retornado, se não houve mudança, então o valor anterior (pdp) deve ser retornado.
Para o caso de alocação de memória como o caso anterior:
MeuTipo * criaTipo(MeuTipo * pdp) {
  pdp = (MeuTipo*) malloc ….
    … Inicializa dados em pdp
  return pdp;
}
Veja que agora não será mais necessário usar o operado * e nem (* ). e agora existe um return que retorna o endereço criado.
o código completo do exemplo anterior fica:
{    …
  MeuTipo * ptr = NULL;
  ptr = criaTipo(ptr)
    …
}
e a função que recebe o endereço do ponteiro:
MeuTipo* criaTipo(MeuTipo * p){    …
  p = (MeuTipo*) malloc ….
    … Inicializa dados em p
  return p;
}
Para exemplificar, uma inserção ordenada em uma lista ligada poderia ser algo como
Lista* criaTipo(Lista * ptr, int valor){
  se (ptr == NULL){     //lista vazia
    ptr = (MeuTipo*) malloc ….
    … Inicializa valor em ptr
    return ptr;
  }
  senão{     //Lista não vazia
    Lista * lTmp = malloc …
    … Inicializa valor em lTmp
    se (lTmp->n < ptr->n){   //insere no começo da lista
lTmp->prox = ptr
return lTmp;
    }senão {
      …
      Trata outros casos de inserção em uma lista
    }
  }
  return ptr;
}
Veja que podem ser retornados: um novo valor caso a lista esteja vazia (ptr = (MeuTipo*) malloc), uma novo valor caso a lista não esteja vazia mas o valor deve ser inserido no começo da lista (return lTmp;), ou pode ser retornado o mesmo valor de ptr (return ptr;).
Se ficarem com dúvidas, deixe um comentário

Proposta do GSoC aceita! Valeu KDE

Dear Wagner,

Congratulations! Your proposal “Rocs support to others Data structure, scripts include and new file format support.” as submitted to “KDE” has been accepted for Google Summer of Code 2010….

Recebi esse e-mail da equipe do GSoC segunda e fiquei muito feliz com a aprovação. Mas antes de comemorar, tem algumas pessoas me perguntando o que é GSoC e como eu consegui isso. De lambuja vou falar do meu projeto 🙂

Primeiro o GSoC (Google Summer of Code) é um projeto onde estudantes trabalham no verão (do hemisfério norte) em projetos de software livre e são remunerados por isso.

Para participar, o estudante deve escrever um projeto no qual descreve o que ele desenvolverá (ou organizar também, um aplicativo não é só código 🙂 ) para uma determinada entidade, que no meu caso foi o KDE. Esse projeto é enviado para o apreciação dos participantes da entidade onde eles votam nas proposta indicando se a mesma deve ser aceita ou não. Ao final um certo número de projetos são aceitos pela entidade e enviados para o Google. O mesmo efetua uma analise sobre esses projetos selecionados e comunica os indicados.

O GSoC é visto por muitos como uma forma de aumentar a rede de contatos e se preparar para o mercado de trabalho, uma vez que o projeto deve ser cumprido e existem prazos a cumprir. Alguns que participaram de edições anteriores passam a agir como mentores. Mentores são pessoas da entidade que auxiliam os alunos a cumprir a tarefa, mas não escrevem nada apenas tiram dúvidas.

Segundo, para mim conseguir a aprovação eu digo que foi em grande parte pelos prévio contato com o projeto, uma vez que eu pude conversar e propor melhorias que melhorariam o projeto e, com isso, consegui captar o que o projeto precisava antes mesmo de pensar em GSoC (que eu nem tinha idéia de participar a poucos meses), e assim escrever uma proposta que tivesse mais chace de ser aprovada

um pouco de história agora:

Nos idos do ano de 2009 do nosso senhor, vim a conhecer algo que veio a acelerar o meu labor como desenvolvedor. Eu acredito, hoje, que o que vim a encontrar naquele tempo seja o Graal dos frameworks para aplicações, poís minha capacidade de desevoldedor aumentou por demais no tempo transcorrido até hoje.

Após consultar o oráculo para mais saber sobre tal frameworke, vim a ser indicado a ler manuscritos, hoje destruidos pela ação do seu dono, onde era explicado sobre como operar tal ferramenta. Então, vejo algo totalmente inesperado e até aquele momento para mim impossível a não a Hercules e seu panteão, mas ví, uma aplicação onde era possível de se criar grafos e interagir com os mesmos usando de scripts, tudo isso em tempo de execução!

Busquei pelos reinos sobre a pessoa que criou aquilo tendo a encontrado reunindo um rebanho juntamente com outros pastores vivendo tranquilamente. Mas me mantive a distância, apenas ouvido seus sermões de conhecimento supreendentes e regozijei-me com suas colocações. Por volta do primeiro mês do inverno, decidi tentar um contato com ele, para saber se ele deseja ajuda com o seu filho, tendo como resposta uma afirmativa. Passei a assistir o crescimento de tal filho, mas mantendo uma certa distânia e apenas indicando ao pai os erros cometidos pelo seu filho. E foi assim até o inicio do verão, quando eu estava preparando algums scripts, ouvi uma resposta após indicar mais uma das peripécias do filho que me fez agir: “Pare de relatar bugs se pode corrigir”. Com isso passei a ajudar diretamente na criação do filho aplicando as devidas correções quando necessário.

Esse ano, como já estava contribuindo com o Rocs, começei a propor algumas possiveis melhorias e implementei algumas, como por exemplo o suporte a plugins de ferramentas, onde é possível rodar algoritmos em C++, por exemplo, sem conhcer quase nada sobre a API do Rocs ou do KDE e o suporte a formatos de arquivos.

Como eu já vinha contribuindo para o projeto, isso aumentou em muito as minhas chances de ser aceito.

Sobre o projeto, eu demorei demais escrevendo, assim fiquem com o resumo, depois explico melhor http://www.socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/kde/t127230762382

KDE SC 4.4 release

Today is the day!

Following the schedule, KDE team released KDE SC 4.4 and a new face to website.
In some days the distros will release the packges, but as allways source code is avaliable to download (vide download.kde.org)
KDE SC 4.4 brings some new features, many improvements, and a lot of bug fixes.

KDE community still growing up and bring news applicartions. This release bring Rocs (aplication to teach graph teory), Cantor (frontend to many matematics applications), and Blogilo (blog client) as some of news applications introduced at 4.4.

KDE SC 4.4 is based in a fresh release of other great software that is Qt 4.6. With new animation api, KDE become more ‘smooth’ and dynamic.

Let me talk about Rocs, application developed by Tomaz. I knew Rocs about middle of 2009. I like graphs, and a IDE to work with it is awesome!
At end of year 2009, i write some scripts to Tomaz put as examples and help to fix some bugs. By now, i start to put some ideas inside the Rocs to be released at KDE SC 4.5, but it will be speaked in nexts posts.

Now go get your source and that force be with you.

Propriedades dinamicas e ‘coisas mais’

Nos ultimos dias Tomaz e eu estamos trabalhando para adicionar algumas features novas no Rocs e corrigindo alguns bugs que aparecem no caminho.

Conseguimos terminar a adição de propriedades dinâmicas, propriedades estas que podem ser adicionadas e utilizadas durante o script. Com elas fica mais fácil trabalhar com alguns problemas de grafos, como por exemplo PRV, CCP, CCCP, e outras siglas legais, uma vez que se podem adicionar propriedades como por exemplo capacidade ou demanda diretamente nos nós, sem ter um vetor separador. Aqui tem uma imagem
Rocs: Now with dinamic properties

Pra quem conhece o Rocs deve ter reparado que os icones dos nós estão diferentes neh? Bom, essa é uma outra novidade (ainda em desenvolvimento) que é os icons pack, onde os usuários podem criar seus prórpios conjuntos de icones (para apresentar sobre VRP, pode colocar o deposito como um prédio e as demandas como lojas, por exemplo) sendo interessante para apresentar em palestras

Foram feitas algumas melhorias para estabilidade no core e alterações na interface.

Se quiserem testar essa versão do rocs, o código fonte pode ser obtido com o svn (svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdeedu/rocs)

Release Party KDE 4.4

Dia 10 de fevereiro de 2010, das 14 às 17hrs, será realizada a release party do KDE SC 4.4 no campus da UNIPAMPA Alegrete.

Esse é um movimento que ocorre em várias partes do mundo, onde colaboradores do KDE se reunem para apresentar ao grande público as novidades dessa que é a 4ª versão do KDE SC 4, além do próprio sistema para quem quiser conhece-lo. Mais locais onde estarão acontecendo releases parties podem ser encontrados em http://community.kde.org/Promo/ReleaseParties/4.4

Dia 10 estaremos apresentando vídeos das novas funcionalidades e dis ponobilaremos um sistema rodando o KDE para testes, alem de auxiliar quem queira instalar o KDE em seu sistema (Linux e/ou Windows)

Essa versão apresenta melhorias no Plasma, Nepomuk (framework de buscas semânticas), foram adicionados alguns novos aplicativos para blog, matemática e teoria de grafos, além de novas funcionalidades no ambiente de desenvolvimento.

Um resumo mais completo de todas funcionalidades podem ser encontradas no site do KDE no Brasil ( br.kde.org ).

O inicio antes do fim

Por volta de julho contatei o Tomaz para ajudar no desenvolvimento do Rocs. Mas devido a ‘medo’ e falta de tempo mesmo (quem manda se envolver com tudo) não tinha pego o projeto pra trabalhar.

Após alguns meses o Tomaz pediu pra mim escrever uns exemplos para o Rocs, claro que aceitei, até pq eu jah tava com vergonha de por me dispor a ajudar e não ter posto o mão na massa ainda.
Devido a um erro em um script, encontrei um bug que fazia o Rocs travar. A resposta do Tomaz: Não abra bugs que pode corrigir:) . não poderia ter sido melhor. decidi que devia resolver.

Depois de lutar um pouco com threads, conseguimos (o Tomaz me deu uma baita mão pelo Gtalk ) e agora posso dizer que sou um ‘colaborador’ do KDE (através do Rocs).

E consegui antes do final do ano inciar a ajudar esse grande projeto que é o KDE através do Rocs, o qual tem várias idéias por serem implementadas para uma próxima versão e que vou ajudar nisso.