libgcal 0.9.6 plus akonadi resources 1.2

Dear friends

It is being almost 3 months since the last public release of both the library and the resources. In the library, no new features on this release, but some improvements and bug fixes. The laundry list goes:

• restored ABI (as noted by Fathi Boudra, gcal_contact_get_im was missing after the work in supporting multiple im fields)
• CMake and autotools buildsystem will install the library in INCLUDE_DIR/libgcal (as per request of Mario Ceresa so it will adhere to Fedora Core packaging policies). Autotools patch by Ademar Reis.
• And a new cleanup function gcal_final_cleanup() to avoid a potentially crash scenario if libgcal is linked with something else that *also* uses libxml. Nice patch by Chris Frey (thanks a lot dude!).

But for the resources, some nice new features:

• IM fields are supported (as a matter of fact, this feature was available in libgcal since 0.9.5 release, but it never made into the akonadi contacts resource). Patch by Holger Kral.
• Fix a scenario were authentication would fail if both resources (gcalendar + contacts) are set while using different google accounts. Now user information is saved in KWallet per resource (and the key also relies on the username), this makes possible the next new feature.
• Multiple users are supported as long you have 1 resource per user. Previously, that would not be possible, because I was saving a single entry in KWallet (so it was overwritten after each new resource inclusion). I have tested with 3 different users *at same time* each one with both resources (contacts and calendar, total 6 resources instances) and its feeling quite stable.
• Fix in authentication dialog, now the configure message reads “Your Google mail username (or user@whaveter.domain.com)”. I received some many bug reports about this, mostly because the previous message didn’t clue the user that hosted accounts are also supported. I’m just not sure if the translation strings were updated…

So, if you are curious, download it from the libgcal project website and have a try (compiling instructions are available in the tarballs). Or wait a couple of months and it should be pre-packaged for you in your distribution.

Known issues:

• Only the main calendar is synced… supporting multiple calendars within the same account is in my to-do list.
• Please, only 1 resource type X 1 user account. I haven’t tested the non sense case of adding more than 1 resource instance type per user account (so you are on your own if you do this).

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:

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? 🙂

6 months of plasma in 10 minutes

Not really… It is actually 7 months of “kdelibs/plasma” (or libplasma) repository activity in 15 minutes (but that would not sound really as attractive as a post title).

Today a fellow co-worker showed to me a really nice application: gource (like ‘source’ but with ‘g’ letter, maybe for ‘graphics’) written by Andrew Caudwell. This application offers some really nifty source code control visualization and supports git/mercurial and other source code control systems using some hacks.

Since internet speed (not even talking about latency…) in Manaus/Amazonas is lacking to say the least, I decided to use git-svn to checkout a specific revision of kdelibs/plasma directory and later I did a rebase to update the code with the trunk.

So, for your amusement, enjoy.

I have some hints about this visualization:

• in the first seconds there is an explosion of files (because I didn’t checkout the code from the very first commit in svn, is like the touched files warped inside of logs)
• the code seems to be rather modular (there are a well defined set of clusters on it)
• development speed is affected by some special dates (feature freeze, Christmas, Tokamak, etc)
• there are a quite varied number of contributors working in libplasma (which is good! KDE is a pretty open community)
• the overall champions in commits are (unsurprisingly!) Aaron and Marco 🙂

Lies, big fat lies and benchmarks

There is the old saying, ‘there are lies, big fat lies and there are benchmarks’, but after my previous post about the jsanim, it was time to try to measure how good or bad the javascript based animations are when comparing it against Plasma::Animations (written in C++).

== what to measure? ==

The first task was to have a meaningful number and frames per second (FPS) sounds like a good idea. The only issue is that QGraphicsView will only update parts in the scene that need redrawing (besides it seems that there is not an easy way to access the draw events without subclassing). My solution was to set a counter for the Animation::updateCurrentTime() method that is called while the animation is running, given that the documentation says that “… neither the interval between calls nor the number of calls to this function are defined; though, it will normally be 60 updates per second.”. Maybe I should call it Function calls Per Second (FCPS). 🙂

Another important factor that can impact hugely is this kind of benchmark is both the hardware as also the graphics system used by Qt (and finally if the window manager has composite effect turned on). My test computer is a macbook (version 4.1), Intel Core 2 Duo (T8300@2.4Ghz), video Intel Mobile GM965/GL960), Qt 4.7 from master repository and I run the tests with composite disabled and got this results.

As the test application, I used the code available in playground/plasma/libs/jsanim, where a set of QGraphicsWidgets (each one drawing a pixmap) will run an animation group where 2 animations (zoom and fade) run in parallel followed next by a rotation.

== equal or not? ==

Next task is to extract any meaning from the results and I remembered what an old statistician professor that I had used to joke “Torture the data enough and it will confess”. I used to be good on this subject (back in the day I wrote some Bootstrap simulations and model fitting for biological data as also geostatistics  studies using R), but it is being 5 years since I last have done any statistical analysis, I was worried about making some mistakes while using more advanced methods.

So I went with the lazier approach and decided to use a boxplot, following bellow:

The js based animations seems to have a somewhat bigger variance (see second boxplot) but overall you can’t really tell if there is a difference between them (just in case, the p-values for t-student means tests was for each animation respectively: 0.54, 0.43, 0.86).

So… what about mobile? I did the same tests in a Nokia N900 (using the opengl and raster engines) and got this data, which yielded the following boxplot:

this time without the js variance and again without any sensible difference between js and C++ animations (p-values: 0.42, 0.16, 1).

== wrapping up ==

From the data (and after asking 4 different people to inspect visually how the animations were running in js X C++ apps), I can say that following the path of using javascript to code the logic of animations in Qt seems to be a valid approach with no sensible difference in performance. Kudos to QScriptEngine (and Qt development frameworks) for making it perform really fast.

There are indeed some issues in this study, following:

• CPU and memory usage: I measure it informally using ‘top’ and they seems to be on the same level, but a more formal benchmarking ideally should measure this variables;
• samples: I was a bit in a hurry and run each animation only 3 times (ideally a bigger sample like 20 should be used).

jsanim: current status

From my previous post about jsanim (javascript animations) where I explained the motivations about the idea, I’m writing to report the current status.

I got stuck while trying to create an instance of a javascript class from C++ side in QScriptEngine, but I was helped by khansen (you rock man!).

Being able to create an instance got to address an important issue in the first PoC: run more than 1 animation. Now each animation type will have a javascript class, where its instance will point to the animation target widget and hold the animation parameters. This design has some advantages:

• uses a single QScriptEngine object (implemented as a singleton);
• can run multiple animations;
• multiple animations can access the same widget;
• is more OOP oriented (the animation loop will call a method on the javascript class);

How fast (or slow…) is it to use QScriptEngine to animate a widget’s properties? What about a video?

Notes: it has 8 QGraphicsWidgets, 24 animation objects (zoom, fade, rotate), running in the Nokia N5800.

What is next is profiling and comparing it against our Plasma::Animation classes doing preferably the same type of work. But since it is still in the very early beginning, it is already looking promising.

God bless America!

Yesterday, people attending camp KDE decided to give a break and go to Stone Brewing Co (that deserves a post for itself!) and later we went to Fry’s electronics. While in our way to there, I noticed a Gamestop store and Ian Monroe saved my day by making a stop in the place (thank you very much man!). 🙂

Thanks to the fact that Nintendo Wii is backward compatible (i.e. it plays gamecube games), I have being trying to find some ‘old’ Gamecube titles (and searched in 4 different gamestop stores in San Francisco around a year ago): Soul Calibur II, Crazy Taxi and Eternal Darkness. The last one is *specially* difficult to find, since was one of the premiere games of Gamecube.

And guess what? I finally found it!

Plasma new animation classes

One of KDE 4 objectives was to create an organic and even more pleasant environment (and it is being achieved with both plasma-desktop and plasma-netbook). One of the features that contributes significantly to achieve a natural look and feel (together with really *great artwork*) are animations.

KDE 4 introduced plasma Animator class with the purpose of applying effects and animations to plasma widgets. With the new Qt 4.6 animation framework (a.k.a. kinetic), plasma effects started to be ported to it, introducing some new animations (e.g. Pulse, Rotation, Stacked rotation, kinetic scrolling) which are already being used in the upcoming KDE SC 4.4.

Kinetic scrolling made its debut in Plasma::ScrollWidget, used internally in uBlog (the twitter/identica plasmoid client) and plasma-netbook (i.e. to scroll through icons in application containment). It has a long story and was rewritten at least 4 times:
– Using a single timer and coordinates for scrolling (with bouncing effect);
– Using percentages for scrolling and properties for position;
– Using coordinates with properties again and implementing the concept of scrolling manager;
– Using QPropertyAnimation to do the animation instead of a timer (and having the bouncing by just changing the easing curve)

The new plasma animation classes has also an interesting story, being submitted through at least 4 big refactorings:
– Initial import based on gSoC project done by Mehmet Ali Akmanalp;
– Animation objects caching;
– Using QAbstractAnimation as base class;
– Reimplementing QAbstractAnimation::updateCurrentTime and non longer using an internal QPropertyAnimation/Group object to actually do the animation;

The good news are that the code is being made more flexible and paradoxically simpler at each review session. What about an example? Say that you want to have that nice pulse effect when a widget name button (i.e.that has QGraphicsWidget as base) is selected you just need to write something like this:


Animation *pulseAnim = Animator::create(Animator::PulseAnimation);
pulseAnim->setWidgetToAnimate(button);
connect(button, SIGNAL(clicked()), pulseAnim, SLOT(start()));


And the same concept is used for the following animations: rotation (2D), fade, grow, zoom, slide, stacked rotation (‘3D’), geometry. Obviously, that depending on the animation type, you got to setup more parameters, like movement direction/reference/distance/axis. Selecting easing curves is also possible, but we are working to have good pre-selected curves that makes sense for each animation class.

Those plasma animations can easily be integrated together with your own animations and directly used in animation groups (i.e. QAnimationGroup) being parallel or linear. Finally, all those classes are being bind with javascript making it dirty easy to have future js plasmoids with nice animations.

So, where to start now? My suggestion is to have a look in kdeexamples where there is a test C++ plasmoid that exercises pretty much all the current available animations.

Next post: video showing the animations. 🙂

Nokia Booklet 3G: KDE and plasma

As in the previous post, I wrote that the Intel GMA 500 drivers for Linux are problematic. The result is that trying to enable composite effects using OpenGL will result in rendering artifacts and crashes in both KDE and Gnome (in a side note, qtdemo will fail with “Application calling GLX 1.3 function “glXCreatePixmap” when GLX 1.3 is not supported!” but at least works with -graphicssystem=raster).

Last Sunday, I compiled Qt 4.6 and KDE from trunk  in the booklet and started to play with it to make it run well. The only way that I found for composite was to use XRender  (yeah, it will run way slower, but it is a workaround while we don’t have good graphics drivers).

As the result, the KDE effects based on KWin were running slow (so the workaround was to change the animation speed to ‘Instant’). The result of this hacks can be seen in the following videos, which I recommend watching in fullscreen (sorry about my Portuguese accented English):

Concluding this 3 parts saga:
– The Nokia booklet is a great hardware and Ubuntu Karmic support most of it out of the box
– Intel GMA 500 is at very best, a problematic GPU in Linux
– KDE and the plasma-netbook both runs smoothly in the booklet (even with lacking drivers)