Sprint 3: Calendar management dialog, cleanups and bugfixes

The Sprint series comes out every 3 weeks or so. Focus will be on the apps I maintain (Calendar, To Do, and Settings), but it may also include other applications that I contribute to.

GNOME Calendar: the new calendar management dialog landed

It’s landed! The massive rewrite of the calendar management dialog reached a good enough shape to land, and so it happened:

The calendar is a fresh new take on the previous one; the individual online accounts rows were removed in favor of delegating it all to GNOME Settings’ Online Accounts panel, navigation is easier and simpler, adding new calendars is a more intuitive operation, and it’s possible to toggle calendars right from the first page.

I’m pretty happy with the rework itself, and splitting it in pages and a controller was definitely the right choice. It allowed implementing the same functionality in a much more well organized way.

Next step is another much necessary rework: remote calendar discovery.

GNOME To Do: polishing rough edges

GNOME To Do received a round of bugfixes and minor improvements to the list archive feature. In addition to that, the triweekly GTK4 update happened, and multiple crashes were fixed.

GNOME To Do is now good enough for me to use it daily, although more improvements are necessary to make it a pleasant experience.

GNOME Settings: nothing

That’s right; this GNOME Settings week was dedicated entirely to something else. There will be an important blog post about it later, but for now, suffice to say it’s an important feature.

Lessons learned & concerns

There were various conclusions I could draw from this sprint.

The first and most concerning one is that, even though dedicating one week per project has increased productivity by a factor of N > 5, it is honestly not possible to keep up with this rythm of work. This is the third sprint only and I already feel that the energy to keep up with this schedule is fading. I want to try and reduce the scope of the changes that I pick up from now on; big changes and new features will have 2 or 3 weeks assigned to them instead of 1.

The second conclusion is that tasks that require design review can only be done iteratively. The traditional model of asking a designer for something, waiting for a mockup to be created, then working on it, is too slow and has too many steps to achieve something. Doing it iteratively means not only that designers get to see the result and suggest changes immediately; it also means developers spend less time switching contexts, and changes are much easier. This is something I will definitely keep in mind from now on.