Contributing to GNOME, great advances!
Finally the next post announced in the “Contributing to GNOME, checkpoint” is here, the last few weeks have been a bit intense working on the GNOME Calendar project, we did some great advances! At that moment, me and Felipe sent a merge request to the maintainers in the first issue (#1232) and were waiting their feedback. In the second issue (#1202), in which we just did some observations on the problem, we were just waiting too. From that point, a lot has happened.
The first issue, #1232
After we sent the MR, Jeff answered us suggesting a small linguistic change in the string we were modifying and Georges also requested some changes in the code, the biggest part being only about coding style. We followed all the suggestions and, finally, our MR was merged!
Our modifications will take part in the GNOME 47 stable version, but right now this is the behaviour when building from the GitLab repository version:
Tooltip displaying the meeting service name
When the meeting service is unknown, the link is now truncated at 50 characters
When the location is not a URI, it’s displayed as usual in its full length.
A wild issue appears, #171
Some days before our MR being merged in the last issue, Jeff asked me and Felipe if we would have interest in a “presumably easy, but incredibly high-impact” bite-sized challenge (his words). We, of course, accepted it! This was the issue (#171) he was talking about: when importing a .ics file to the calendar, the dates can have a explicit time zone or not, and the Calendar was wrongly assigning the UTC time zone to the latter case, as the RFC5545, which defines the iCalendar format, explictly says that events without time zones should not be bound to any one in particular, but stay in the local one.
The issue was created six years ago and some devs had already sent some patches to it, but they were never merged. The correction was pretty simple, just a one-line change, but Jeff also asked us to make add a new test to ensure this would work and not break anything else (also to make it more robust). So, we did it! Felipe and me just followed the correction the other devs had alredy suggested, made a new test to check if the time zone was being correct set in events and sent the MR. Again we made some coding style mistakes, but after fixing them, Georges merged it. This was a great way to understand how tests works and I feel much more confortable proposing some more!
The (old) second issue, #1202
The last issue clarified for us how the Calendar handles time zones and brought us some ideas on this one (#1202): right now, all-day events have its time zone set to UTC, but this looks to be a problem, as they are converted to the local time zone before being displayed on the lateral menu and the time zone offset makes it to be wrong by one day in some cases. So, we made a commment in the GNOME Calendar Matrix channel bringing up this discussion, if assigning the UTC time zone is really the correct way to do it. We are now discussing it and investigating some related issues to see if we can have some new ideas on how to deal with it.
Now
I was expecting to come in this post with just one MR, a lot of progress has been made. We are now talking with the other devs in the Matrix chatroom about the last issue and figuring out how to deal with it. We are also planning to study some other time zone related issues to propose new tests, as this looks to be a important thing to the project. I think that is it, happy with all of it and very excited for the next contributions.
This post wasn’t made as part of the discipline MAC0470 - Desenvolvimento de Software Livre, BCC - IME - USP, its just to keep our progress reported somewhere :) .