The use case

Image you are writing a widget or a piece of an application interface and you want to rotate something based on a mouse click. For instance, you may have a widget that looks like a rotating knob, or a round analogue gauge.

For this post, let’s use a car dashboard speedometer. What I want here is to click somewhere on the gauge and have the needle rotated towards the current mouse position. Check this video of how it should work.

The problem

In Qt, rotating a widget is easy in the context of QtQuick or QGraphicsView, just define the “rotation” property to the desired angle and you are all set. The problem here is to find out what the desired angle is.

Here I want to find out which is the angle formed between a given mouse position and centre of the gauge, or the origin of the needle rotation. Getting the mouse position is easy in QtQuick, simply watch the “mouseX” and “mouseY” properties of a MouseArea. But what about converting that to an “angle” ?

In mathematical terms what I want is to convert the mouse position from linear coordinates (X,Y pair) to circular coordinates (angle, radius pair) with the centre of the gauge being the origin of my plane. But designers using QtQuick really don’t want to deal with that.

The solution

I made a Qt class meant to be used as a “model” or “helper” for both C++ and QtQuick applications. This class hides the trigonometry required for that conversion by exporting a set of properties, namely:

• originX
• originY
• x
• y
• angle
• radius

So how would we use it in our example?

1. Set “originX” and “originY” to the centre of the gauge. That’s the origin of the needle, right?
2. Set “x” and “y” to the current mouse position. In QML that would be “x: mouseArea.mouseX” and “y: mouseArea.mouseY”.
3. Read the value of “angle“. In QML that would be something like  “needleRotation.angle: angleModel.angle”

Then QtQuick data binding system will handle everything else. Every time the mouse moves, the properties “x” and “y” will be updated, the model will then recalculate the values of “angle” and “radius” causing the needle to update itself.

Below you can see a diagram of that behaviour. Note that the opposite also works, that is, once I explicitly set an “angle” and “radius” in the model, the values of “x” and “y” are automatically updated.

Relationship between AngleModel and different coordinates

The Source

To grab the code go to Qt Components Gitorious and check:

• examples/clickable-dial
• examples/angle-model

Hope you enjoy it. Comments are always welcome.

While QGraphicsView and QML already provide rectangular clipping, it does not support clipping to arbitrary forms and opacity, something we would need in order to implement the “moving bars” transition used in the image slider I mentioned above.

I expected QGraphicsEffect to be suitable for that usecase but I had no experience with it, so I decided to try and make a proof of concept effect class that would clip an arbitrary QGraphicsItem to the shape of a bouncing circle.

A more useful class would be one that received as parameter a mask image instead of the “hard-coded” bouncing circle, but I’ll let that as an exercise to those reading

Code is attached, I complied against Qt 4.6 and it works fine. Just run:

# qmake
# make
# ./effect

l class would be one that received as parameter a mask image instead of the “hard-coded” bouncing circle, but I’ll let that as an exercise to those read.

Download and try it here.

UPDATE:  If your default graphics system is not raster, ie. if you get errors like:

QPainter::setCompositionMode: Blend modes not supported on device

Try running the example as follows:
# ./effect -graphicssystem raster

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!

Now I’d like to give some overview of how it works and why we’re so excited about it.

To do that I’ll talk about the layouts that already existed in Qt, the Anchor Layout basic usage and finally, the situations that are better handled by the latter. From now on assume I’m talking about the QGraphicsView framework and where you read “widget” or “layout”, understand that I refer to QGraphicsWidgets and QGraphicsLayouts.

Existing QGraphicsLayouts

As of Qt 4.5, the exiting layouts available were the Linear and the Grid layouts. With those, as their names imply, users could have their widgets arranged side-by-side or in a spreadsheet-like fashion, with support for merged cells included.

It was not possible however to lay items out of the screen or overlap them, total or partially. Besides that, some cases would require several layouts to be nested in order to achieve the desired result.

The Anchor Layout concept

Previous layouts work like this: the linear layout would require you to add items to the layout in a given sequence and then those would be arranged side by side (or one on top of the other); in the grid layout the concept is similar, but items are now associated to X,Y indexes to represent the row and column where they should be inserted.

The Anchor Layout breaks with this paradigm in the sense there is no pre-defined concept of how should the items be arranged. The final position of each item is totally dependent on how you set the anchors. In other words, the anchor layout is a very, very flexible layout.

While most layouts are flexible to some extent and allow you to configure parameters like spacing between items or margins, the Anchor Layout brings flexibility to a new level. It was also our goal to make the setup process something easy. We didn’t want to expose hundreds of abstract parameters to the user, instead, we wanted to provide a high-level API and concept. Besides making the coding more rewarding, that would make it easier to translate into C++ code, the UI designers ideas and way of thinking. That’s what the anchors are about.

In this layout, each item has six anchorage points, which are Left, Right, Top, Bottom and the Horizontal and Vertical centers. The user is then responsible for connecting the anchorage points of different items to the others, and to the anchorage points of the layout itself. These connections are made through the use of the so called Anchors, that have well defined sizes.

Then, based on:

- the anchors created,
- the size hints of each item, and
- the size of the layout itself

the layout engine calculates the appropriate geometry of each widget.

Real world Anchor Layout use cases

Here at openBossa we have been involved on the development of rich-UI applications for long, and it was with that experience in mind that we started contributing with the guys from Qt on the development of the QGraphicsAnchorLayout.

Bellow you will find a few use cases of ours that were not handled by existing layouts and work fine with anchors.

Transition between screens

We often want to make a transition between two screens of the same application. Imagine the user performs an action that should hide the current screen and show another one.

In a rich UI application we probably want to animate such transition, one of the alternatives is to apply a fade-out or blur to the current screen until the new screen is seen. To achieve that, we want both screens to occupy the same position on the screen, the old one being in front of the new one (higher Z value). Then it’s just a matter of changing the opacity of the screen on the front and voilà, we have the effect.

So, how do we use a standard layout to make one widget (next screen) occupy the same position as another one (current screen)? We couldn’t do that with existing layout. With anchor is just a matter of anchoring both screens edges to the layout edges (right of item to right of layout, left to left, and so forth).

Usage of AnchorLayout to set two swallows on the same place.

Off-screen items

Another common trick used in UI animations is to have an off-screen item get “inside”  the screen or vice-versa. For instance, imagine a toolbar on the top of the screen that shows or hides itself in an animated way, like “walking into” or “out” of the screen. The idea here is to have two states (QStates maybe?) where the toolbar widget is on-screen in one of them, and off-screen in the other.

Again, with standard layouts we could not create this “off-screen” state. With anchors it’s just a matter of anchoring for instance, the bottom of the toolbar to the top of the layout, thus, the toolbar will sit right above the layout, ready to enter the screen (in an animated way) when necessary.

Usage of AnchorLayout to set a toolbar on or off-screen.

Organic setup

There are also those cases where we have several items arranged on the screen in a very organic way as drawn by the UI designers. Often it’s not practical (or possible) to define that arrangement in terms of several nested layouts. However, with a single Anchor Layout, all items can be arranged precisely.

Try it

There are other situations where such a flexible layout is helpful, however I hope the cases above exemplify the kind of problem we are trying to solve. Please, give it a try, let us know of your impressions. We really appreciate all kinds of feedback, either on usage, performance, API, features, and so forth. All of these will be taken into account so you can have a nice new tool ready for use in Qt 4.6.

Enjoy

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

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