Posts filed under ‘animation’

Sliderlayout

It all started with a simple problem: I want to change from one list of things to another, doing a ‘slider’ like transition (like you would do for example in a music player when you choose an artist and go to another list with the tracks).

That sounds pretty simple, right? Just fire a QPropertyAnimation (or if you are using Plasma, a SliderAnimation is even better) and animate the position of 2 widgets.

But what if I want to have those widgets inside of a layout (e.g. QGraphicsLinearLayout)? After all, I want my UI to scale between different window sizes, screen resolutions (and in mobile devices, adjust to screen rotations).

Hum… you could draw your widgets *over* the linear layout and check for resize events of the main widget *while* correctly positioning your set of widgets in the scene. But that sounds a bit too much hack-ish.

I asked 2 friends about this very same issue and one suggested me to create a layout with this behavior. Initially, I was not sure about it, after all, I have never worked before with QGraphicsLayouts and I got almost no time to have something working.

Well, the good news are that it only took me a couple of hours to get this:

[blip.tv ?posts_id=3856759&dest=-1]

Explanation: it is a layout were you can add several widgets and move from one to another by calling next()/previous(). And since it is just a layout, can be inserted in another layouts (in this case, inside of QGraphicsLinearLayout).

Maybe a bit of code would help to explain… say that you have 2 widgets and you want to move next when the current one is clicked:

Item obj1, obj2;

SliderLayout *slider = new SliderLayout;

slider->addWidget(&obj1);

slider->addWidget(&obj2);

connect(&obj1, SIGNAL(clicked()), slider, SLOT(next()));

slider->setCurrentWidgetIndex(0);

and you are done.

The secret here is to keep hidden all the widgets (except by the current one) and in the slider event, animate the position of both widgets (the current and soon-to-be-current widget) while correctly repositioning the widgets in the scene (and setting to show state both widgets of course).

Since I have the movement methods on this layout as slots, I have to derive from both QObject and QGraphicsLayout (and that I’m not completely happy, anyone has suggestions to workaround that?).

I have tested this layout (integrated with *far* more complex widgets) in varied devices (from ARM@430Mhz up to Intel Atom@1.6Ghz))and it behaved pretty well, basically because I’m only animating the position of 2 widgets. It might happen that if you have an overly complex widget, that your hardware is not able to do the animation with good frame rate (but here you can workaround by hiding some of the content of this overly complex widget, and that will be probably the subject of my next post).

There are 2 other remarks about the code:

  • I used Plasma SliderAnimation just because it was easier, but it could be replaced by a QPropertyAnimation
  • Since Plasma Animations expect to receive a QGraphicsWidget, I assumed that you are going to supply a QGraphicsWidget to the SliderLayout. But the real requirement could be a QGraphicsItem, since it is the position that is being animated.

You can get the code here, my personal sandbox for experimenting with plasma animations and other stuff (please, please, we *do* need to migrate away from svn and start using git) and look for src/lib/sliderlayout.cpp and src/example/slidertest.cpp. I wonder when the feature freeze of KDE is over, if this could be part of libplasma.

Maybe this concept could be expanded so there would be a layout class and the animation behavior (fade, rotate, slide, etc) be defined by a delegate. Anyone is tempted to help me to develop this further? 🙂

Advertisements

July 4, 2010 at 9:05 am 1 comment


Calendar

December 2017
M T W T F S S
« Apr    
 123
45678910
11121314151617
18192021222324
25262728293031

Posts by Month

Posts by Category