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.