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!

Além das novidades desta versão, confira também os mobile-demos! (Código Aqui)

Pausa!

“O que é Qt?” -> Veja um resumo aqui (embora esse artigo em português da Wikipedia precise dumas atualizações).

“Qt Creator?” -> É uma IDE para desenvolvimento em Qt.

mobile-demos? Tá, esse explico aqui =)

São alguns conceitos de aplicações criados pelos designers e desenvolvedores do openBossa visando principalmente dispositivos de telefonia móvel (vulgo ”celulares’) Symbian / S60 — Plataforma que move cerca de vários celulares em todo o mundo, notoriamente (mas não exclusivamente) aparelhos Nokia.

Se você tem um celular S60 5th edition (N97, 5800), você encontra os pacotes em: http://qtlabs.openbossa.org/mobile-demos/

Quem tem celulares S60 3rd (por exemplo N95, N85), também podem rodar esses demos! Claro que com restrições, já que eles foram pensados para telas sensíveis a toque. Existem alguns branchs no gitorious com algum suporte ao teclado, quem sabe num futuro próximo teremos novidades =)

Se você já é um dos felizes proprietários de um N900, também temos pacotes para você!

Se você está querendo ver do que se trata isso tudo, está rodando Windows e não quer se envolver com compilação, instalação de bibliotecas, etc, aguarde que se possível ainda hoje haverá algo para você veja os links abaixo do vídeo =)

Enquanto isso, confira o vídeo:

Update:

Aqui estão as versões para você que quer brincar com os demos no seu desktop. São binários com Qt 4.6.0 linkados estaticamente, para você que ainda está com uma versão anterior do Qt ou nem tem instalado.

Versão para Linux

Versão para Windows

Mac: Estou sem mac no momento, contribuições são bem-vindas =)

Nós estaremos por lá! Eu e Anselmo Melo vamos ministrar um mini-curso de Qt 4.6 no sábado, 24/10. Teremos também palestras de Artur Souza, sobre o Plasma Netbook, Caio Marcelo e Eduardo Fleury falarão sobre Qt Layouts, Ana Cecília (aninha) vai falar sobre Usabilidade em OSS usando seu GSoC como estudo de caso e Kenneth vai falar sobre o Webkit.

Caso queira entrar em contato, basta nos procurar nas referidas palestras ou no stand do INdT que estará em algum lugar do evento.


Nos encontramos por lá!

jeez

Cerca de 3800 pessoas estão inscritas para o evento e acredito que será um grande encontro com outros desenvolvedores, pessoas que conheço apenas por IRC ou e-mail, chance de conseguir parceiros para o  Qt Labs Americas em outros países da América Latina, e claro, aprender e conhecer novas coisas.

Aprender e também ensinar! =) Se você olhar a programação do evento, notará que alguns colegas farão apresentações lá. Entre eles, Artur de Souza (MoRpHeuz) apresentará uma atualizada versão de sua palestra sobre Plasma Netbook (incluindo uma demonstração bem legal =). Já Caio Marcelo e Eduardo Fleury tratarão sobre novas possibilidades para o desenvolvimento de interfaces gráficas em Qt e KDE. Ainda temos nosso colega importado Kenneth Christiansen, que falará sobre QtWebkit.

No último dia  (Sábado, 24 de Outubro) Jesus Sanchez-Palencia e eu ministraremos um minicurso sobre o que há de novidade no Qt 4.6. Assim, pessoas interessadas no desenvolvimento com Qt e também KDE terão uma grande oportunidade de aprendizado, pois existem outros 2 cursos no programa, ministrados pelos colegas do Live Blue, além é claro de poder ter contato com outros membros da comunidade KDE que estarão por lá =)

Além dos já mencionados, destaco também a apresentação que Ana Cecília (annieC) fará sobre um estudo de usabilidade em projetos de software livre.

Aos que forem para o Latinoware, nos vemos lá! Aos que não puderem comparecer, fiquem atentos que em breve teremos notícias.

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!

Sim! E o que é PySide, você pergunta? São bindings da biblioteca Qt4 para linguagem Python criados pelo INdT e a Nokia (Moi, tamperelaiset!) sob licença LGPL. Minha equipe (não sou dono dela, minha no sentido de “nossa sem incluir o interlocutor”) trabalhou feito louca e o lançamento foi uma beleza: tivemos um retorno positivo da comunidade e as notícias estão aparecendo em toda parte.

E fornecemos não apenas o peixe mas também a vara (na boa): o gerador de bindings também está disponível. Mas qual a importância disso? Dada a notícia vou explicar com calma.

Antes de continuar repare na garrafinha de Prince of Persia no logo do PySide. É a marca usada em projetos do Qt Labs Americas.

Os Bindings

O motivo primário da criação do PySide foi prover bindings Python da Qt4 sob a licença LGPL, para se alinhar com a oferta da Nokia da própria Qt4. Várias possibilidades de como fazer foram analisadas, e antes dessa frase começar uma discussão técnica infinita, todas as opções tinham pontos bons e ruins, mas não tão diferentes assim. A idéia do Smoke foi uma das que mais gostamos e vale uma menção. No fim optamos por alterar um gerador de bindings existente (mais sobre isso abaixo) e usar o Boost.Python para fazer meio-campo com a API CPython. Trocando em diagramas coloridos esse é o PySide:

O Gerador

Escrever bindings pra uma biblioteca tão massivamente grande quanto Qt é uma tarefa… não, não é uma tarefa, é uma punição. Pessoas de bom senso que somos demos uma pesquisada por aí e optamos por adaptar o código do QtScript Generator, que por sua vez é um fork do Qt Jambi Generator, e ambos são geradores de bindings QtScript e Java, respectivamente, desenvolvidos pela Trolltech (quando ela se chamava Trolltech).

O esquema de geração de bindings funciona assim:

O arquivo global.h inclui todos os headers (pelo menos os desejados) da biblioteca sendo processada, e também define e desdefine flags do preprocessador. Arquivos typesystem.xml são descrições de como a biblioteca deve ser exportada para a linguagem alvo: classes rejeitadas, métodos renomeados, tipos convertidos e, muito importante, códigos escritos à mão para casos especiais e onde eles devem ser inseridos. Se não houver necessidade de alterações esse xml será apenas uma simples lista de classes, enums e funções.

Notem que não apenas forkamos o QtScript Generator, mas a convertemos de uma aplicação monolítica num esquema lib (que chamamos de API Extractor) + front-end gerador. E mais uma figura pra explicar a idéia:

Teoricamente os projetos dos quais derivamos código poderiam ser alterados para usar o API Extractor e compartilhar essa base de código (e bugs, e fixes, e melhorias). Além disso, o sujeito pode escrever front-ends que gerem outras coisas que não código: grafos de relacionamento entre as classes, estatísticas, algo-que-eu-não-pensei.

Agora a parte não tão bela. Num mundo perfeito o gerador de bindings C++ para Python geraria bindings de qualquer biblioteca C++ para Python, contudo da forma que se encontra agora o gerador serve apenas para bibliotecas baseadas em Qt. Grande vergonha! Considerando que o foco era criar o bindings Qt e os lançamos em versão beta, sugiro nos perdoar. Claro que está nos planos resolver isso e tornar o gerador uma ferramente genérica e útil para mais pessoas.

Informação demais! Por hora, baixem, testem, relatem bugs e aproveitem. E se estiverem se sentindo sociais entrem no canal #pyside no FreeNode e assinem a lista de discussão.

Durante o aKademy / GCDS foi divulgado pela primeira vez o Qt Labs Americas e foi dito que em breve teríamos mais informações. Pois bem, chegou o dia! Hoje está oficialmente no ar o site http://qtlabs.openbossa.org !

Mas você me pergunta: “O que é isso, afinal?” – Citarei um trecho do texto que está no site:

O Qt Labs Americas é uma iniciativa do openBossa visando o desenvolvimento de comunidades com interesse em Qt e KDE em todo o território do continente americano, começando pelo Brasil.

Até então, o conteúdo produzido sobre este tema era focado no mercado Europeu e disponibilizado principalmente em Inglês. Os desenvolvedores brasileiros possuem a partir de agora um ponto de referência onde encontram, também em Português, informações sobre o desenvolvimento do Qt no Brasil e no mundo.

Mais detalhes? A versão completa (em Português, Inglês e em breve em Espanhol) está em http://qtlabs.openbossa.org/about/ . Lá também você encontra relação de projetos que estão de alguma forma envolvidos e os parceiros desta iniciativa.

Está de alguma forma relacionado com Qt e/ou KDE e quer fazer parte? Representa alguma universidade brasileira? Entre em contato através de qtlabs@openbossa.org .

Assine os feeds dos blogs e das notícias! Para quem preferir, as notícias também são repassadas para o identi.ca e twitter.

Dúvidas? Escreva nos comentários (do blog de origem deste post) ou entre em contato conosco via e-mail!

Nele você pode ver que temos 3 layouts (um vertical, um horizontal e um grid), aos quais vamos adicionando itens. Também fazemos resize nos layouts e temos a transição animada entre eles.

Para chegarmos nesse resultado, implementamos o QGraphicsLayoutProxy. A idéia é ter um layout proxy em cada layout da sua aplicação, mas que apontem para um mesmo widget. Quando uma mudança entre layouts ocorre, os proxies se responsabilizam por animar a transição dos widgets pelos quais são responsáveis.
Por enquanto a transição está “hardcoded” no LayoutProxy, mas já estamos trabalhando na versão final da api.
Tem sido um trabalho bastante divertido, principalmente porque estamos trabalhando em cima do “bleeding edge” do Qt 4.5 – que por sinal sai como LGPL agora em março – e as api’s de animação e de states (QStateMachine) está muito boa, acreditem!

Morpheuz também fez um post com um ótimo overview e Fleury postou uma excelente explicação sobre os “internals”… Inclusive com figuras bastante explicativas!

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