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!

You may have been following the buzz around bad 2D performance of nvidia-drivers, specially with KDE 4. Well, I found out that QEdje was running slower than it could on my machine due to the same reason.

Zack Rusin released yesterday a nice benchmark utility for Qt, QGears2, which I used to measure the effect of Lemma’s suggestion on KDE’s techbase.

My machine is a 2.4GHz Core 2 Duo / 2gb / nVidiaGeForce 8600M 256mb MacBook Pro, running Gentoo ~x86.

The first tests were conducted using:

• Xorg-server 1.4.2
• Xorg 7.3
• nvidia proprietary drivers (nvidia-drivers) 173.14.12

The second test session were conducted after the following changes:

• nvidia proprietary drivers (nvidia-drivers) 177.67 beta (I’ve unmasked them in Gentoo)
• Added PixmapCacheSize and OnDemandVBlankInterrupts options to xorg.conf
• applied InitialPixmapPlacement and GlyphCache hacks:

  nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

GEARSFANCY results:

Old setup:

• -image –> 42 fps
• -render –> 35 fps
• -gl –> 396 fps

New setup:

• -image –> 67 fps
• -render –> 41 fps
• -gl –> 476 fps

Let me know of your results.

Cheers,

Fleury

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

I’ve been working on the QEdje project and, while studying possible optimizations, our team was interested in measuring whether we could benefit from using MIT’s X11 shared memory extensions. Among other tests, I managed to run x11perf on the N800.

A simple patch was needed before cross-compiling it. This because this app has a hard-coded window size of 600×600 pixels, more than what’s available in our 800×480 screen, thus leading to a X error message, complaining about get screen parameters.

I also reduced the square side size from 500 to 400 pixels in the XShmPutImage and XPutImage tests (shmput500 and putimage500).

The results were absolutely favorable to the use of the shared memory extension as you can see below:

./x11perf -shmput500 -sync

800 reps @ 8.6566 msec ( 116.0/sec)

./x11perf -putimage500 -sync

360 reps @ 14.8336 msec ( 67.4/sec)

For those willing to reproduce the tests, the patch is available below and should apply cleanly to x11perf 1.5.

Download x11perf 1.5 patch

Cheers,

Fleury

The bug sympthons are a very unresponsible system after leaving the screen locked for several hours, ie. all night, for instance, simply unlocking it was almost impossible. It was also possible to see intense flickering of the screensaver unlock dialog.

Logging to the terminal was possible though and I found out that there were many kdesktop_lock instances running (more than 80) and they were eating up all machine resources. Killing all of them (ie. pkill kdesktop_lock) would bring the system back to life.

To understand what was happening I left a tiny script logging the number of kdesktop_lock instances all night so I could check the results the other day. It was then interesting to find out that two instances were being spawned every 5 minutes. Note that my screensaver timeout is 5 minutes, and I use two screens on KDE.

Probable cause, maybe due to the existance of a second monitor, KDE is failing to tell the screensaver is already active and is spawning a couple more, one for each screen, everytime the screensaver timeout is due.

Unfortunately I’m currently unable to investigate this bug in deeper detail due to our current QEdje project but, meanwhile you can avoid it by disabling automatic screensaver and starting it manually when needed.

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