A nova versão está disponível para download em qt.nokia.com, em versões pré compiladas para Windows, MacOS e Symbian, além do código fonte (para todas as plataformas). Usuários Linux podem baixar e compilar o fonte ou então instalar usando os procedimentos normais de cada distribuição, tão logo estejam disponíveis os pacotes desta versão.

Entre as novidades dessa versão estão:

• API de Animação (QAnimation)
• Máquina de Estados (QStateMachine)
• Novo layout (QGraphicsAnchorLayout)
• Suporte para a plataforma Symbian, o que permite que o Qt rode em dezenas de milhões de novos aparelhos

A documentação atualizada com todas as novas classes está pronta também, ou pelo Qt Assistant ou online.

Outro fato marcante desta versão é o fato de ser a primeira após a abertura do repositório Git do Qt, e assim marca uma integração cada vez maior com a comunidade. Nesse sentido esperamos que todos usem, testem e mandem opiniões e reports de eventuais bugs, para que as próximas versões sejam cada vez melhores!

Para ilustrar um pouco, um vídeo feito pelo pessoal aqui do openBossa mostrando o 4.6.0 rodando em diversos aparelhos!

Para finalizar, algumas fotos do time do Qt.

Em Oslo

Em Berlin

Em Brisbane

Em Munich

Parabéns pessoal!

Hoje gostaria de dar uma visão geral sobre como este novo layout funciona e sobre o porquê de estarmos tão animados com isso.

Para tal, vou falar um pouco sobre: os layouts que já existiam no Qt, o uso do Anchor Layout e finalmente, os problemas que são melhores resolvidos por ele. De agora em diante assuma que estou escrevendo sobre o universo QGraphicsView e assim, onde ler “widget” ou “layout”, entenda que me refiro a QGraphicsWidgets ou QGraphicsLayouts.

QGraphicsLayouts existentes

Até o Qt 4.5, estavam disponíveis os layouts Linear e de Grid. Com eles, como seus nomes indicam, usuários poderiam ter seus widgets alinhados lado a lado ou em formato de tabela, com widgets ocupando uma ou mais células.

No entanto, não era possível organizar os itens para que ficassem fora da tela ou que se sobrepusessem, total ou parcialmente. Além disto, para obter o resultado desejado em alguns casos, era necessário utilizar diversos layouts encadeados.

O conceito do Anchor Layout

Layouts anteriores funcionavam assim: o layout Linear pedia que você adicionasse items ao layout em uma determinada seqüência e assim os itens seriam arranjados lado a lado (ou um sobre o outro); no caso do layout de Grid o conceito era similar, mas com itens associados a índices X,Y para representar a linha e coluna onde eles deveriam ser inseridos.

O Anchor Layout quebra com este paradigma no sentido de que não existe um conceito pré-definido de como os itens devem ser dispostos. A posição final de cada item é totalmente dependente de como você cria as âncoras. Em outras palavras, o Anchor Layout é um layout muito, muito flexível.

Apesar da maioria dos layouts serem flexíveis até certo ponto, e permitirem que se configure parâmetros como o espaçamento entre itens ou as margens, o Anchor Layout eleva a flexibilidade a um novo patamar. Foi também um dos nossos objetivos, fazer com que o processo de criação do layout fosse algo simples. Não queríamos expor centenas de parâmetros abstratos ao usuário, ao invés disto, nós  queríamos disponibilizar uma conceito e uma API de alto-nível. Além de fazer com que seu uso seja mais gratificante, isto facilita a tarefa de transformar em código C++, as idéias e a maneira de pensar dos designers de interfaces. E é assim que surgiram as âncoras.

Neste layout, cada item possui seis pontos de ancoragem, que são esquerda, direita, topo, base e os centros horizontal e vertical. O usuário por sua vez, é responsável por conectar os pontos de ancoragem de diferentes itens entre eles, e com os pontos de ancoragem do próprio layout. Essas conexões são feitas através das tais âncoras, que têm tamanhos bem definidos.

Depois, com base em:

- as âncoras criadas,
- os tamanhos mínimo, recomendado e máximo de cada item, e
- o tamanho do layout propriamente dito.

o layout calcula as geometrias apropriadas para cada um dos widgets.

Casos de uso do Anchor Layout no mundo real

Aqui no openBossa nós temos trabalhado no desenvolvimento de interfaces ricas há um bom tempo, e foi com essa experiência como bagagem que começamos a contribuir com o pessoal do Qt no desenvolvimento do QGraphicsAnchorLayout.

A seguir você irá encontrar alguns dos nossos casos de uso que não eram bem tratados pelos layouts existentes e que são bem mapeados para âncoras.

Transição entre telas

Nós freqüentemente precisamos fazer uma transição entre duas telas de uma mesma aplicação. Imagine que o usuário executa alguma ação que causar o sumiço da tela atual para que uma nova apareça.

Em uma aplicação de interface rica nós provavelmente gostaríamos de animar tal transição. Duas das alternativas seriam tornar transparente ou embaçar a tela corrente até que a que está por vir se faça visível. Para alcançar tal efeito, nós precisamos que as duas telas ocupem a mesma posição na tela, sendo que a mais velha deverá estar na frente (índice Z maior). Em seguida, basta aplicar o efeito à tela que está na frente, por exemplo mudar sua opacidade, e pronto, temos o efeito!

Então, como poderíamos usar um layout comum para fazer um widget (a tela nova) ocupar o mesmo espaço que outro (a tela velha)? Não dava. Agora com âncoras, basta ancorar os lados de uma tela aos lados da outra (direita com direita, topo com topo, etc) e pronto!

Uso do AnchorLayout para colocar duas telas no mesmo lugar.

Items fora da tela

Outro “truque” que usamos na animação de interfaces é fazer um item “entrar” ou “sair” da tela. Por exemplo, imagine uma barra de ferramentas no topo da tela que desliza pra dentro da tela e depois pra fora. A idéia aqui é criar dois estados (usando QStates talvez) onde a barra está dentro da tela em um deles,. e fora no outro.

Mais uma vez, com os layouts comuns não poderíamos criar o estado “fora-da-tela”. Com âncoras, basta ancorar a base da barra ao topo do layout, por conseqüência a barra será colocada logo acima do layout, pronta para entrar na tela quando necessário.

Uso do AnchorLayout para colocar um widget fora da tela.

Disposição orgânica

Existem também aqueles casos onde os designers criam um protótipo de tela com diversos itens arranjados de maneira disforme ou “orgânica”. Na maioria destes casos não é prático (ou possível) ter de usar diversos layouts encadeados para definir tal arranjo. No entanto, com um único Anchor Layout, todos os itens podem ser organizados de maneira precisa.

Experimente!

Existem outras situações não mencionadas onde um layout tão flexível também é útil. Eu acredito no entanto que os exemplos que coloquei aqui são suficientes para mostrar o tipo de problema que estamos tentando resolver. Por favor, experimente e nos diga o que achou. Todo o tipo de opinião é realmente bem vindo, quanto à forma de uso, performance, API, recursos e assim por diante. Tudo será levado em conta para que vocês tenham uma boa ferramenta nova para usar no Qt 4.6.

Aproveitem

Para olhar o código fonte ou fazer o download de um tarball do código fonte, visite o Gitorious do Qt.

Como o nome indica, a versão atual só é compatível com o canvas Graphics View, ou seja é um QGraphicsLayout, e não um QLayout. Esta versão ainda está em desenvolvimento e possui defeitos conhecidos, especialmente quando os itens são organizados de maneira impossível. No entato melhoras virão ao longo do próximo mês, podem esperar.

Enquanto a documentação não está pronta, veja a declaracão da classe QGraphicsAnchorLayout para conhecer sua API. Logo que possível eu publicarei algum material explicando melhor o seu uso.

Como sempre, comentários são bem vindos!

To browse the source or download a tarball, visit Qt Gitorious.

As the name implies, the current version is only available for the Graphics View Framework, ie. it is a QGraphicsLayout, not a QLayout. The current version is still under development and still have know issues, specially with impossible arrangements of items. You can expect improvements through the next month though.

Check the QGraphicsAnchorLayout header for its public API while documentation is not available. I’m going to post more about its usage soon as well.

Comments are always welcome!

We’ve just uploaded a new video showing our latest animated layout example.

You can check it at:
OpenBossa’s Youtube Channel

Or here:

Rather than showing how to animate from one layout to another, this example shows how could a Qt user create his/her own custom layout that uses QGraphicsLayoutProxies internally to animate its items.

From the usage point of view, once the layout is ready, all one has to do is to add or remove widgets to the layout or resize it to see them animating to the right places.

Enjoy!

Layouts

If you are familiar with Qt, chances are you have already used layouts and widgets a couple times. If you haven’t, try to think of a layout as a set of geometry rules, or principles, that are applied to the children widgets when the layout is associated to a parent widget.

In other words, imagine you have a box drawn on the screen, and, inside it, three widgets, say, a button, a checkbox and a label. Now imagine you want these three components to be organized somehow inside the box, horizontally aligned for instance. In Qt all you have to do is to apply an horizontal layout to the box and its widgets (button, checkbox and label) will follow the rules enforced by that layout.

The Goal

While existing layouts work fine for forms  other static UIs but lack something when seek the development of rich, animated, interfaces, as the one in Canola 2. In these scenarios animating from different layouts and/or different layout states is a must, and that’s what we went after. As the starting point, we focused on the Graphics View Framework and therefore started with QGraphicsLayouts rather than QLayouts. After talking with the guys at Qt Software we found a solution that enables:

• animated transitions from one QGraphicsLayout to a completely different one (grid to linear, for instance);
• animated transitions from one QGraphicsLayout state to another (when an item is added for instance, or items are re-arranged);
• works with all third-party QGraphicsLayout subclasses you may have coded to fit your personal needs; and
• works with all third-party widgets.

The result

A video is worth more than a bunch of words. In this demo we show:

• Addition of new items to a visible layout;
• Change between three different layouts (horizontal, vertical and grid); and
• Changes in the parent widget size.

Can’t see the video? Watch it on YouTube:

http://www.youtube.com/watch?v=M3HbmrNvQl4

The Usage

This post is focused on the internals but read MoRpHeUz recent post about this subject for the end-user point of view.

The Solution

We had a strong requirement of providing compatibility with 3rd party layouts and widgets, we also couldn’t break Qt’s API or ABI. To understand the next step it is necessary to know a little bit about how QGraphicsLayouts work in Qt, but, in a nutshell what happens when a layout is applied to a widget is the following:

• When the parent widget (the outer box) undergoes a change (is resized for instance), its associated layout is informed about it.
• The layout recalculates new geometries for each of the child widgets (the label, the button and the checkbox).
• The layout sets the new children geometries.

What we did was to create an Animated Layout Proxy that sits between the Layout and each of the child widgets. Due to the way Qt is organized what is expected then is that our proxies pass along the geometry change information they received from the layout to the item below it. The trick here is that rather than sending the geometry change request immediatelly, the Proxy creates a QAnimation from the former state to the new one. The result after the animation is finished is the same, the child widgets were set to their new geometries, what is different however is that the widget moves in an animated, sleek way, rather than at once, which is the standard.

The high-level diagram below shows how the Animated Layout Proxy is inserted in the existing QGraphicsLayoutItem hierarchy. Other relationships were omitted to keep things simple.

Cheers,
Fleury

O vôo inicial já antecipado no Contato Radar é o seguinte:

AZU 4151 (diário) OPR E195
2200 VCP 0115 REC

AZU 4152 (diário) OPR E195
0245 REC 0600 VCP

Espera-se que em breve inicie-se o segundo diário nos seguintes horários:

AZU 4150 (diário) OPR E190
0955 VCP 1310 REC

AZU 4149 (diário) OPR E190
1340 REC 1655 VCP

Valor do trecho por enquanto, na Azul, incluindo datas do Carnaval é de R$ 239,00 .

Para comparação, na TAM, simulação para o início de Marco:
- Voando para GRU, R$ 389,50.
- Voando para VCP (com conexão), R$ 549,50.

Expectativa para diminuição dos preços por parte das congêneres. 

www.voeazul.com.br

Check it out at:
http://www.bossaconference.indt.org/programme

And for those who haven’t seen it yet, don’t miss the Bossa Conference teaser at YouTube:
http://www.youtube.com/watch?v=IHM8cUoxmio

Don’t miss this one!

I had just begun working at OpenBossa (the company) when I attended to last year’s Bossa Conference was delighted to experience this unique event on Free and Open Source solutions for mobile embedded devices.

Bossa is different because it goes beyond the high quality talks, those who attend to Bossa have the chance to hang out with the speakers and other participants in a very casual way, all of that while enjoying the best-in-class Summerville Beach Resort, in the northeast of Brazil. Expanding your network and chatting about the latest technologies is incredibly amusing when done inside a pool and under the bright sun of Porto de Galinhas, Pernambuco.

A teaser for those who could not be present at last years edition.

Online subscription is opened already at the Official Site.

Don’t forget to read about this year’s list of speakers that include, in no special order:

Andreas Aardal Hanssen
Carsten Haitzler (Rasterman)
David Zeuthen
Gustavo Barbieri
Hadi Nahari
Holger Krekel
Iñaky Pérez- Gonzalez
Karen Sandler
Koen Kooi
Marius Bugge Monsen
Olivier Crête
Patrícia Montenegro
Scoot James Remnant
Sebastian Kügler
Simon Hausmann
Thiago Macieira
Zack Rusin

Best regards!

Eu, Eduardo Fleury, e Rodrigo Vivi, teremos o prazer de apresentar duas palestras na manhã do Domingo, dia 04 e agradecemos antecipadamente a presença de todos.

As palestras são independentes porém relacionadas, a primeira, Embarcando no Linux para sistemas embarcados (Rodrigo Vivi) ocorrerá as 09.00h de Domingo e cobrirá os conceitos fundamentais das plataformas móveis embarcadas baseadas em Linux, mais especificamente o Mamona e o Maemo.

Na seqüência, às 10.15h apresentarei a palestra Velejando com o Linux para sistemas embarcados na qual discutirei aspectos focados no desenvolvimento de aplicações para estas plataformas, incluindo questões como o ciclo de desenvolvimento e uma comparação entre linguagens de programação, partindo então para uma introdução à linguagem Python e suas principais características.

Links:

• Ensol 2.0 – http://www.ensol.org.br/2008/
• Embarcando no Linux para sistemas embarcados – http://www.ensol.org.br/2008/node/74
• Velejando com o Linux para sistemas embarcados – http://www.ensol.org.br/2008/node/73