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

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

Well, now I figured out that adding the “-u” flag to emerge restored the expected behaviour.

Maybe I was supposed to use “-u” since day one but the fact is I didn’t, and emerge worked fine until now. Anyway, if any of you face the same issue, try “-u”.

Cheers,

Fleury

Since March 3rd, 2008 I live and work in Recife, PE, northeast of Brazil and work in the Canola project. You can now reach me at #canola @ freenode, look for “efleury”.

Right now I’m attending to the Bossa Conference on Open Source Software for Mobile Embedded Platforms ’08 in Porto de Galinhas, PE. Watch for some photos soon.

More info at: http://www.bossaconference.indt.org/

Fabi, bienvenue a le monde du blogs!!!

http://fabithome.blogspot.com

2.10pm David Bowie – Ashes to Ashes.

2.21pm Manic Street Preachers – Autumnsong

2.40pm Alanis Morissette – Ironic

3.48pm The Clash – Should I Stay or Should I Go

3:59pm Snow Patrol – Chasing Cars

4:07pm Stereophonics – It means nothing

5:25pm Amy MacDonald – Mr rock

Cheers!

With this in mind I’m starting this section to share some of my music tastes, grab your headphones and enjoy! Feel free to comment, suggest, whatever u want

And now… I’m listening to London’s Virgin radio, check it out @ http://www.virginradio.co.uk/listen/

A first time suggestion by Morpheuz!

Cheers!