Gnome-Calendar

Introduction

In the last blog post about GNOME, I mentioned that Otávio Silva and I chose to work on GNOME as the final project for the discipline MAC0470 (Introduction to the Development of Free Software). More specifically, we chose to work on GNOME-Calendar. In this post, I will share the issues we chose and the steps we followed for our contribution.

GNOME Contribution Workflow

GNOME has a friendly contribution workflow. One of the things that caught our attention as we decided which project to work on in the last part of the semester was how the contribution process for GNOME was well documented. Their welcome page shows the projects they have available and describes in detail the steps to make a contribution. In addition, each project has some guidelines to help. GNOME-Calendar, for example, asks us to choose an issue to work on (or create a new issue), describe how we plan to fix the issue, and only then send the Merge Request.

Once we had chosen the issues, something else caught our attention. Our first idea was to set up a virtual machine, install the necessary dependencies, and only then build and run the calendar app inside the VM. Like in the Kernel contribution, that would allow us to create a separate environment to test our app without crashing our own calendar. However, with GNOME, none of that was necessary. In the guidelines for a contribution, they advise the contributors to use GNOME Builder. GNOME Builder is an IDE that not only allows us to easily clone the project repository but also installs its dependencies and allows us to build a mock of the app that is already separate from the app on our computer. That made the contribution process a lot easier! Instead of spending hours setting up the proper environment, we could spend our time looking through the issues and thinking about the solutions. This was definitely the project with the easiest workflow that we worked on.

First Issue

Since this was our first time contributing to GNOME, we decided to start with a "newcomers" issue. That would allow us to explore the code and learn how it was structured, giving us confidence to work on a more complex issue later. The first issue we chose involved changing the display of links in the tooltips of the calendar.

Tooltips are the text-boxes that appear next to the mouse pointer when you hover over an event on the calendar. They are used to show concise information on a given event, like the time and the location of the event. If you want to see more information, you can click on the event and a popover appears with more details. A nice behavior implemented in the popover is to simplify the display of online meeting services. For example, if a meeting is scheduled on Google Meet and has the following link: "https://meet.google.com/aaa-aaaa-aaa", the popover has code that parses the URL, recognizes that the meeting is on Google Meet, and shows the name "Google Meet" together with a button to join the meeting.

On the tooltip, however, only the full link of the meeting would be shown. That is not ideal because tooltips are not clickable, and some meeting services have very long URLs. So instead of showing useful concise information, the tooltips can get long and confusing. The issue we worked on proposed a solution to this problem. In the tooltips with online meeting links, instead of showing long URLs, we could show only the meeting provider.

In order to implement that, we thought about using the same parsing function that is already implemented in the popover to parse the URLs in the tooltips. That way, if the meeting location is a known meeting service, we show the name of the service instead of the full link. If the meeting is not on a known service, we limit the length of the URL to make the tooltip smaller. And if the location of the meeting is not a link but an actual address, we show the full address, which can be useful (unlike an unclickable link).

Following the GNOME-Calendar guidelines, we wrote our proposal in the issue discussion on GitLab and waited for a response. Jeff Fortin, one of the maintainers of the calendar, replied to our solution, gave us some suggestions, and tagged other maintainers to verify it. However, only one of the other maintainers replied. That made us unsure whether we should submit a merge request or wait for their reply. We decided to write the code, make it ready to submit, and work on another issue while we waited for a response. That is where we are so far.

Second Issue

While we waited for a reply on our first issue, we chose to work on another one. This time we decided to implement tests on GNOME-Calendar. Tests are extremely important to make sure that the code has the expected behavior and - especially in open source projects - it is useful to make sure that new code doesn't break old features. We saw that first-hand when we worked with other open source projects like Kworkflow and the Linux Kernel. GNOME-Calendar, however, has very few tests implemented. Jeff Fortin, one of the maintainers of the calendar, made an entire discussion about this in an issue on GitLab. He called the community (and especially those with an understanding of C) to work on this. We thought this was a great issue for us!

In his issue about tests, Jeff Fortin suggested people look at the issues labeled with "timezone". Timezones apparently lead to a lot of bugs in the calendar. Looking through those issues, we found a very odd behavior reported in issue #1202. We thought that it would be a good idea to fix this issue and at the same time write tests for it. That is what we set out to do! We had to explore a lot of the code to understand the bug, but we finally understood the problem. Before sending a merge request, however, we followed the guidelines of the project and first discussed our findings with the rest of the community. Our observations can be found in the GitLab repository. Now we are waiting for a response from the maintainers to see if we are in the right direction before writing our MR.

Conclusion

With each new project, we learn more about the practical aspects of open source! Working on GNOME, we saw the difference that having organized documentation and contribution workflow makes to large projects like GNOME. We also experienced some of the overhead of having to wait sometimes weeks for a response on issues. Nonetheless, we also saw the importance of having multiple people looking at the same code. If everybody was working from Canada, for instance, maybe the bug with the India timezone would be harder to spot! I hope we can continue to work on GNOME and finish these contributions that we've started.