Filipe Saraiva: Stands de comunidades de software livre: analisando o stand do KDE no FISL 13

O KDE Brasil já tem uma certa tradição em criar stands legais nos eventos em que participa, stands chamativos, com muita coisa para ver e mexer.

Não foi diferente no FISL 13. Considero até certo ponto uma coroação de todo nosso processo de montagem desses espaços nos últimos anos, resultado do esforço colaborativo de todo mundo que passou pelo KDE Brasil e montou um stand pro KDE.

Panorâmica da área das comunidades com o Konqi ao centro. Foto por @brunobuys

Gostaria de apontar alguns elementos que tornam os stands do KDE Brasil legais a partir desse que montamos no FISL 13. Espero que esse texto sirva de auxílio para todas as comunidades que planejam montar seus próprios stands. Também listo algumas falhas que tivemos nesse stand específico, para tentarmos corrigir em instalações futuras.

Pontos Legais

Um cartaz que nos identifique

O banner que estamos usando desde o aniversário de 15 anos do KDE tem um significado interessante para nós – são vários pinos sobre a América Latina, indicando que estamos presentes por aqui.

Também pode ter uma conotação de dominação territorial, lembrando o jogo de tabuleiro War. Mas tenho a impressão que essa interpretação é quebrada (ou, ao menos, amenizada) por termos pinos de cores diferentes juntos, além da frase em destaque “Fazendo história juntos!”.

Souvenirs

Ter lembrancinhas com a marca do KDE no stand é sempre bom. E vende bastante – o que nos faz ter grana para comprar mais souvenirs para o stand do próximo encontro.

Esse ano no FISL tinhámos bottons (incluindo os Konqi regionais), camisetas e adesivos. Também é legal para sortear alguns no fim do evento.

Demonstrações do projeto

É importante ter seu projeto executando em um computador e disponível para quem quiser se aventurar. No FISL a Melissa gravou alguns screencasts de manipulação do plasma e plasmoids, e ficou rodando no netbook dela.

Seria bom ter isso em uma projeção, mas infelizmente não conseguimos no FISL. Comento sobre isso no tópico “O que faltou”.

Pessoas receptivas

Devemos sempre ter o stand abarrotado de pessoas do projeto abertas para conversar e explicar como tudo funciona: seja o projeto em si, algum software específico, a comunidade, e tudo mais.

Decoração

Decore o stand, deixe-o aconchegante e chamativo. Balões nas cores do projeto espalhados pelo chão são uma boa. Se você tiver algo que chama muita atenção e faz as pessoas se aproximarem do stand, como um dragão verde bonachão de 2 metros de altura, use-o!

O que faltou

Televisão/Projeção

Ter o software sendo executado nos computadores do stand é legal, mas seria muito melhor tê-lo em algum projetor para que grupos de pessoas pudessem visualizá-lo. Um data show ou uma televisão são muito bem-vindos para isso.

Infelizmente não tínhamos nada disso no FISL, o que prejudica bastante quando vamos apresentar o KDE principalmente para os novatos – e acreditem, muitos novatos batem no seu stand perguntando “o que é isso aí”, “quem são vocês”, e por aí vai.

Até tentamos, no último momento, alugar uma tv de plasma mas o preço era extremamente proibitivo. 200 reais a diária de uma tv é muito caro. Vamos tentar nos organizar melhor para o próximo FISL – já que no Latinoware, o outro evento de maior porte que o KDE Brasil participa, tvs são fornecidas para os stands de comunidades pela própria organização do evento.

Mídias com o KDE

O KDE é um projeto upstream, e normalmente as pessoas que usam nosso software o utilizam a partir de uma distribuição Linux – ou seja, há uma comunidade que pegou nosso código fonte, compilou, empacotou e distribuiu a sua base de usuários. Isso facilita a vida do usuário final, que não precisa compilar o KDE para usá-lo.

Por outro lado, isso torna um tanto difícil para nós distribuirmos mídias com o KDE em um evento como o FISL. A pergunta seria: “qual distro iremos distribuir para quem for ao stand?”. E a resposta a ela pode suscitar algumas questões complicadas, por exemplo: “o fato do KDE Brasil estar distribuindo mídias da distro X significa que vocês endossam essa distro e não as outras?”. Com se vê, essa decisão pode ser muito polêmica.

Fazendo uma busca no Distrowatch para listar apenas distros que usam KDE, é retornado o resultado de 115 distribuições. Entre elas, a grande maioria utiliza o kernel Linux, mas outras usam BSD e Solaris. Ou seja, além de escolhermos a distro ainda teremos que escolher qual kernel distribuir.

Sem negar as polêmicas que surgiriam daí, penso que atualmente, sem distribuirmos nenhum cd com KDE nos eventos, estamos deixando de lado talvez a principal maneira de divulgarmos o projeto. Afinal, do que adianta alguém chegar no nosso stand, curtir tudo que tem lá, gostar do que viu, mas não levar em mãos um cdzinho pra instalar em seu próprio computador e começar a usar nosso software?

É uma discussão que acho que teremos que realizar no KDE.

Conclusões

O texto procurou listar alguns elementos típicos dos stands do KDE, principalmente na configuração usada no FISL 13, e citou qual a função de cada um. Também discuti algumas coisas que senti falta e que pode ser interessante para nossos futuros stands.

Apesar de ter alguns tópicos direcionados ao KDE e de ser de certa forma um texto rápido, creio que as dicas aqui presentes podem ajudar comunidades a montarem seus stands em eventos desse tipo. Penso que não há nada de novo ou mesmo inovador no que descrevi, mas se você já foi em algum evento de software livre há de concordar que existem vários e vários stands sem nada – e em algumas vezes até só com um carinha imerso em seu notebook, sem se dar ao trabalho nem de receber as pessoas que visitam sua área.

Então é isso pessoal, fiquem a vontade para mandarem seus feedbacks na caixa de comentários logo abaixo.

Francisco Fernandes: GSOC 2012: Pencils down

Hi all!

Today we have the final pencils down for the Google Summer of Code 2012. It was a wonderful experience do this work along with an awesome team such as the Krita developers. So much learning, and yet so much to be learned, that only a summertime it’s not enough.

Along the course of this project, I made some changes in many things, like the integrator, the particle implementation, mouse dynamics calculation and other features, which appeared while the job was advancing in its results. However, the initial functions related with the sand painting style were always the final purpose, so they endured.


I described some of the implementations we made so far and what is yet to be done. I put a few links to past blog posts that described some of the features developed in more detail.

What we have

The problems concerning the Pouring operation was made in this post. There are some things to do, but for now, I believe that the current state will do. The Pouring set some properties related to the grains, such as size, mass and friction, which modifies the way the spread operation work

The brush settings widget: we have the brush settings and the grains settings. Most of them have a diference in the Pouring operation mode.

Once we add grains in the canvas, we can Spread them like a regular sand painting technique. Initially we had some numerical errors related with the grains positions and velocities. To fix this problem was really hard but we accomplish good results without compromising performance.

Some errors were due to mouse velocity calculation. In some situations, mostly when we move the mouse very fast, the time interval becames very small, close to zero, resulting in ugly results in the mouse velocity estimative. Fortunately, Krita already had some code with a solution for this, so I just had to understand what was done and adapt in my situation.

I made a video of an experiment :

Note that the particles are not erased while spreading. Taking a closer look we see that the particles are painted in new positions, although some of them act a little out of the expected behaviour.

From the videos and images some of you could think that the brush works only in grayscale, but it does work in other color models :

We made strokes of the Pouring operation with different colors in each one.
After that, we did some Spread (the well defined white spaces) to show it working in the color grains. The main drawback in this Spread operation is the grain color handling. When we update the grains positions we repaint them using the current color (when putting a grain in a new position) and background color (when “erasing” the particle previous position). We can improve that by holding the color used in the Pouring operation inside the Particle class and deleting the previous position using a alpha channel painting.

 What is missing

There are a few more things that were planed to be done, but I didn’t have time to do it. Again, to the Spread operation work properly it took a very good effort so it could emulate the sand behaviour while the user painted using it.

As explained in this post, we divided the canvas in a number of grid cells so it could apply the Spread only in those which are under the mouse position.
However, the grains which are under the  brush radius should have been spread as well. So one of the things to be done is the to extend the grid cell selection under the mouse radius, not only to the mouse position. There is also the posibility of customizing the grid size for user convenience: larger cells for faster computers, smaller cells for slower computers.

A missing feature is the mouse “particle” customization. The spreading is made by emulating a particle in the mouse position with the same size as the brush radius. However, the mass and friction for the brush are the same as the current configuration of the grain particles, so it’s not a very user friendly setting scheme, since the grains settings is only, obviously, for the grains.

Another problem is when you save a document where you used the sand brush. When you load it, the particle positions are not retrieved, although we can use the created KisAnnotation to do so.

And now?

Well, now we wait for the evaluation. I tried to put a good documentation in the code so anyone can understand what is happening in each part of it. Although some things are missing, most of what was proposed was made
and the main features are working well. I need to do some more tweaks to make the brush more user friendly, but for now, the visual results are satisfying.

I really hope I can continue working in this brush in the next years so it can have a behaviour even more beffiting with the actual behaviour of sand painting. But we will make more plans when we are sure that everything went okay in the evaluation.

Until next time!