Disclaimer: This blog post is going to summarise the experiences I made while implementing animation for the GtkVBox< widget and my thoughts about widget animation in Gtk+ so far. This blog post is not going to be about animation in themes because this is another issue. Of course there are intersections, I’ll point to them when they arise.

By the way, this is one of the longer posts. If you’re interested in this topic you should bring a bit of time with you. 😉

The question is how can we support the application developer to create dynamic user interfaces and at the same time increase the user experience while preserving the advantages of Gtk+‘s box model? Let’s have a look on this short video to motivate this idea with a working example of how animation for widgets in Gtk+ can look like.

What have I done? First I derived from so the original implementation is not touched directly. Then I slightly modified the size_alloc function by saving the computed GtkAllocations and removing direct calls of gtk_widget_size_allocate. I modified add and remove so I can start the animation at the right time. I also added a function called my_vbox_pack_start_n which inserts a widget at a given position so one is able to preserve the original packaging order. You trigger the animation by simply adding or removing widgets to the vertical box as usual.

You find to code here: http://github.com/troja84/af/tree/master/

  • tests/myvbox_a.h

  • tests/myvbox_a.c

  • tests/test-vbox-animated.c

Let me talk about some points in regard to the main topic.


In the example I derived my animated version of GtkVBox from the original one. The advantage is that the animation code is well separated so when an application developer wants an animated widget she has to explicitly select that version. On the other hand you increase the amount of redundant code because you have to slightly modify some functions in order to implement animations. The question is if an additional gtkvbox_animation.[h|c] would be more suitable in case of maintainability. Personally, I like the current implementation very much and I would prefer to add the slight modifications to the original class because these are not so harmful.

May you have noticed the problems when the widgets overlaped each other. At the moment I don’t know how to influence the, let’s call it z-position (the code draws the animated widget first but as you can see this doesn’t help…). That is why I’ve implemented the second animation which is more Gtk+ like (in the way that the widgets do not overlap each other while the animation is running) but this doesn’t work well with widgets which have a minimum size like the buttons in the example.

A further issue is artistic freedom. Should we provide standard animations or do we have to provide an API which enables artists to modify the animations in a significant way? The current implementation is following the first approach. I’m not sure if other widget toolkits or OSs offer more freedom so references are very welcome. 🙂



Animations are not suitable at any place at any time be it by computing power, battery power or personal taste. That is why a discussion about the infrastructure is important. Furthermore, this is something which also affects the discussion about animation in themes.

Infrastructure in this case means an API which offers functions to influence the state of animation on the system level in a way that is transparent for the application and application developer. At least one should be able to turn animations on/off. 😉 There is already a property called gtk-enable-animations in GtkSettings which might be useful for the beginning.


That’s it for now. Remarks are very welcome! 🙂