Wrapping up GSoC 2021

This year’s GSoC has been a great opportunity to learn and to contribute to the GNOME project. Let’s recapitulate what has been done in the libadwaita animations project, what is left to do, and how the future looks like.

What has been done


We started by designing how the animation API should look like, taking into account all the pieces we wanted to fit in and the constrains and limitations of the ecosystem. Part of this work was researching how third parties have solved this issue, studying how the APIs of Android, Flutter, and CoreAnimation work.

We ended with this UML diagram, which would loosely guide the development efforts from so on:

UML diagram of the API design


Libadwaita already had code for managing timed animations, but it was all private and not prepared to be exposed as a public API. It also had code Alexander and I prototyped for spring animations, but the same applies, it was not ready to be exposed yet. Refactoring the existing code was a good exercise for learning the intricacies of GLib and GTK. That refactor was already merged and can be checked here:



With that ground work already laid, I started working on implementing the AdwTimedAnimation class:


To test the new code I implemented a quick test in the libadwaita demo:

Demo of the TimedAnimation implementation

The demo is fully interactive albeit it is not hooked to the controls on display, but can be tweaked with the GTK Inspector (the animation is exposed as a property of the parent AdwWindow). The code for this can be checked at:




Once everything seemed to work without issues I started moving all the relevant pieces of code from the base AdwAnimation class to the AdwTimedAnimation subclass:


And while doing so I had to port all the libadwaita codebase to use the new TimedAnimation implementation:


Once all of that was done I started abstracting the target object to its own class, taking inspiration from GtkShortcutAction. The animation target is a delegate which gets called each animation tick, and it’s the responsible to applying whatever value the animation has at each moment. Right now we only have a callback target, but this refactoring will allow to implement, for example, a property target which will automatically bind the animation to an arbitrary property of an arbitrary widget:


There is an open MR with all these changes in



While it usually is not a good idea to document things before they’re fully implemented, I deemed convenient to do it in this case to wrap things up regarding GSoC. With that in mind I’ve been adding docstrings to everything which will be part of the public API:


Note this is also the last commit in the GSoC context, so if you want to test the work done that’s the best point to check it out. The project compiles successfully and without warnings, and should be trivial to test following the instructions at https://wiki.gnome.org/Newcomers/BuildProject.

The work is not yet finished though;

What’s next

My involvement with the GNOME project and with this particular task is not done yet. I have a clear roadmap to finish the animation API, which loosely looks like:

  • Finish writing the other Animation Targets
  • Open the API for Timed Animations
  • Refactor the physics based animations to use the base AdwAnimation
  • Expose them in the public API too
  • Implement Implicit and Multi animations in the same manner
  • Ask GNOME designers for mockups on the relevant demos for the animations
  • Document everything

This was a big project from the beginning, but I’m really happy to have laid the groundwork to implement everything else this summer.

Some final words

What GSoC meant for me

C is a scary language. It should be, it has a very steep learning curve, and while a lot of us are very decent at self-learning things, I personally couldn’t have learned what I learned without someone experienced mentoring me and guiding teaching me all the intricacies of C and GLib/GTK. I’m certainly not new to GTK, but in these last few months I’ve learned more on how it works than in years. And I’m glad I did, as I’ll be able to involve myself more on the project from now on. This leads me to grant my final words to my mentor, Alexander.

My mentor

I think I’m telling no secret when I say GNOME is very, very lucky to have someone like Alexander Mikhaylenko among its contributors, and I’m not only talking about their incredible capacity to bring to life in a matter of minutes the most incredible projects (each time they tweet the price of the bread rises, I swear). They were incredibly patient and incredibly helpful for me, going above and beyond each single time I requested their help. So, thanks, Alexander for all you do for this project and the human quality you always show.

A quick update on libadwaita’s animation API

Last time we left on the general API design. Since then I’ve been refactoring the existing animation-related code so we can reuse it for our public API. Part of that refactoring has been converting the current boxed-type adwaita animation code into a gobject class. I’ve learned a lot of how GObject works under the hood by doing so, so I expect to be a lot quicker implementing the next milestones.

After that work, which is already merged, I started working on timed animations, and moving functionality from the baseclass “adw-animation” into it, as well as starting opening the API (which was completely private until now).

I quickly prototyped a demo page for said timed animations (which is highly WIP, from design to phrasing):

timed animations demo



GSoC update – designing an animation API

The first step at implementing any kind of API is to design it. The two first weeks of GSoC I’ve been researching how other platforms expose their own animation APIs, trying to understand how they work and taking inspiration for our own implementation.

Based on that and on talks with both my mentor (Alexander) and Jonas Dreßler (an experienced GNOME Shell developer who has fought with animation API designing before) I’ve come with the following UML diagram:

Temptative UML diagram for the libadwaita animation API

It doesn’t reflect everything we want to accomplish but it is a good enough roadmap of the coding I’ll be doing during the following weeks.

The main thing to note here is an internal base animation class, which will be inherited by Fling, Spring, Timed and Multi animations. Fling and Spring will be physics driven animations, Timed will be your usual explicit animation, and Multi will allow to group and handle several animations in a timeline.

Some though has been given to implicit animations as well, but we don’t have proper API design for those yet.

Getting ready for GSoC 2021

Hi, I’m Manuel Genovés, a Spanish physicist, somewhat artist and programmer by accident. Some of you may know me for Apostrophe, a nice little app I maintain for quite some time now. This year I decided to further step up my involvement with the GNOME project so I signed up for the GSoC program.

I’ll be working on an animation framework for libadwaita, the new GNOME library. It’ll allow apps to add semantic movement to their components, and hopefully it’ll make the current code more maintainable.

Mentoring me is Alexander Mikhaylenko, one of the creators of said library. I hope to learn a lot from them and from the work I’ll be able to do on this project.