GSoC 2018 Final Evaluation

As GSoC is coming to an end, I am required to put my work altogether in order for it to be easily available and hopefully help fellow/potential contributors work on their own projects. 🙂

All of my work (during the GSoC period!) can be found on this link.

GSoC has been an amazing experience and opportunity. I have learned lots, made a lot of friends and found something I’d really love to keep on doing further. 🙂

Our initial plan can be found in its own issue right here, issue 224.

First off, a few goals have been unfortunately left out as there has been a lot of going back and forth regarding how we want to do certain things, which ones to prioritize and how to best set an example for the consequent work.

At its prestige, through this project we will have tests both for most critical and used operations of Nautilus, and for the search engines we use. Further on, I’ll provide links for all of my merge requests and dwell a bit on their ins and outs while posting links to my commits:

Add dir-has-files test, the code can be found here: a fairly small and simple function I started to work on in order to get used to working with the GTest framework (although I had some experience from the merged file-utilities test which was merged before the start of GSoC) and set the cornerstone on how we want files and folders to be managed.

Add file-operations-move test, the code available here: the first large operation whose tests we merged. With this we learned we need to create several different hierarchies and that we’d need synchronous alternatives to the operations we’re about to test.

Copy, trash-or-delete file operations tests, whose code is in this folder: after the move operation, things must have went smoother, right? Copy was more or less straight forward, yet trashing and deleting posed a few difficulties as they involve interacting with the user a lot (e.g. confirmation for deletion, confirmation for permanent deletion and the likes of these dialogs which we wanted to avoid as we were doing testing). Once these were added, we realized (as the tests are being ran in parallel) we wanted to prefix the file hierarchies in order to prevent multiple tests from deleting (or trying to access) the same file (which might have been wrongfully deleted by another executable subsequently).

Test library, undo/redo of operations and search engines, which can be found here. This is still a work in progress at the moment of writing this, although the final pushes are more or less about polishing up the code, its documentation and making sure the commits are consistent and make sense in the work tree. Undo and redo operations took quite a bit of time as they have several callbacks in the call chain and they proved cumbersome to debug and work out. With a little help, we decided it would be best not to go with synchronous alternatives, but rather isolate the calls in their own main loop, which signals when it reaches the final callback. Although undo and redo have mostly been merged, some follow up work will be needed as our environment right now does not allow trashing (which means undoing copying a file for instance would work, but not its redo). Search tests were not as difficult as we had a small test regarding the main engine which we only needed to update and make sure runs fine, before proceeding with the following engines. Definitely, the one which proved most difficult was the tracker engine as we need to index a virtual file in the tracker before we run the engine, in order for it to be found. After all this work, I decided we’d reduce the lines of code by a good chunk using a test library, which allows undoing/redoing operations in a blocking main thread, creating and deleting different and varying in size file hierarchies for the purpose of testing (library which will hopefully make following contributions on Nautilus a bit easier and maybe set an example for other GNOME apps).


Bottom line, there’s still a bit of work ahead of us, but I’m confident I’ll manage to do some of them myself, while also trying to make it more approachable for other (or newer) Nautilus contributors.


This july I attended the Gnome Users and Developers European Conference taking place in Almería, Spain.

Initially, I had no idea what to expect out of it. I have been told it’s a great event with people from all around the world and a lot of fun stuff going on. After booking both my flights and my lodging, first thing I did was sign up for the event. The registration process gave us the option of volunteering there. Having attended a few other events (read: music festivals, heh) as a volunteer and barely knowing anyone who would be at GUADEC (aside from my mentor and a couple of fellow GSoC students), I concluded this would be a good way to make new friends while helping around wherever needed. I am glad to say this was a great call and I enjoyed it a lot. Registration desk was mostly what I helped with, but at need, I also helped with introducing speakers (which also meant I introduced my mentor Carlos’ talk!), handing microphones at the Q&A part of the talks and a few other things. Volunteering felt great and (should I attend next year’s GUADEC) I’d love to get more involved in it, maybe even coordinate the volunteers or help coordinating them.

While volunteering was fun, the nitty-gritty of GUADEC are the talks and BoF’s (Birds of a Feather) taking place. I attended quite a few of these (and thoroughly enjoyed as I previously had very low knowledge on the subjects) such as: Matthew Leeds’ “P2P distribution of flatpaks and ostrees” (which made me realize a few things about how we currently distribute our products and had a really good demo at the end to wrap everything up nicely), Kat’s “Plan your testing” (which, as you might’ve guessed, I wanted to attend considering my project’s main focus), Benjamin Otte’s “Have you ever developed for a GPU?” (One of my favorite talks as it seemed to have a different approach compared to the others and put things into perspective with simple yet self-explanatory demos), Carlos Soriano’s “DevOps for GNOME” (whose approach might’ve just revolutionized GNOME in the last year or so) or Tobias Bernard’s “Designing GNOME Mobile” (which, again, felt like a breath of fresh as the subject fit Tobias like a glove and it stirred up further discussion on the matter from the attendees). During the BoF’s days, I took part to the GitLab workshop which showed intricacies on how the gitlab ins and outs work on large scale projects and (one of my favorites!) the Beach BoF! On the first BoF day I managed to get most of us interns together for an evening at the beach. Sooner or later, it all turned into a sandcastle competition! Fun was plenty and two fellow interns decided to create their own BoF at the beach the following day (and it was a success, bringing together both the new blood and the veterans of the GNOME community in order to have some fun together). While I barely knew anyone coming here, everyone was friendly, welcoming and overall quite chatty so the social events were a resounding success (the castle visit and the flamenco show being my top 2 picks!). I can (and am glad to) wholeheartedly say I left GUADEC with more friends than I had before getting off my flight there.

All in all, I would like to thank all of the people whom I got to know better at this event: Sam, Matthew, Niclas, Ruxandra, Iulian, Jiahui, Bastian, Julian, Jordan, Carlos, Kat, Ben and all of the lovely GNOME people who made me feel I’m part of their community!

I’d love to wrap this up with a photo from the Beach BoF (courtesy of Sri Ramkrishna):

Nautilus File Operations 2.0

Following (and during) my latest blog post I was in the middle of my final exams session. While that has concluded eventually and I managed to pass everything just fine, that meant less time hacking and toying around with nautilus’ operations I’ve been working on.

More work was put in the aforementioned move operations until it was a finished product that would set the tone for the following operations as well.

With the move test out of the way, following operations could (more or less, with some needing extra nitpicking) be approached in a similar manner, which we tried to do, also giving them a nice sense of modularity.

Nowadays, I’ve been focusing on finishing the copy/paste test and debugging the ins and outs of the trashing/deleting functionality. After a few fights with multiple G_BREAKPOINT’s and moving the code back and forth trying to provide us an asynchronous alternative while still keeping the code clean and functional, I managed to come up with a test meant for both deleting and trashing. My work on the copy/paste component can be seen here and the trash/delete test should be in its own merge request here.

Hopefully, by the time I finish with these, all tests should look like this:Screenshot from 2018-06-28 16-18-45

And not like this (which happened more than I’d like to admit during the actual writing of the test):

Screenshot from 2018-06-28 16-32-46

Nautilus File Operations

The first thing I was to start working on under my mentor’s guidance, Carlos Soriano, was the implementation of unit tests.

While unit tests are meant to be fairly short and simple, tackling individual instances of a functionality or component, Nautilus would not really allow us to do that. Due to Nautilus’ nature and its tight relation to I/O operations, unit testing for us meant cherry-picking the simpler functions which we use and testing these. However, for the larger, more important components, we’d rely on integration tests, which represented one of the following items on our list.

We started working on nautilus file operations first, which involves functionalities such as copy/paste, move, trashing, deleting. Before this, although I had contributed one unit test before, I decided I would start small. So, while going through our file-operations code, I found a function which tests if a directory contains any children files. As I needed to get a better hold of the libraries we would work with (the glib testing framework, in particular), I decided to write an unit test for this function. Fortunately, its implementation was straight-forward, more or less, so testing it did not prove too difficult (designing some tests and the edge cases). The merge request I opened on it was accepted, after a few changes, and is now in our master version (as you can see here).

Next, I wanted to go with something bigger, something which we outlined when talking about what we wanted to test exactly, so copy/paste it was! As per my previous experience, I tried creating a couple of small file hierarchies and copy/paste-ing these expecting everything to go smooth. Boy, was I wrong. What followed was my mentor explaining me why it did not work as I would suspect it to and how to work on it. Turns out, pretty much all of these operations are asynchronous, so before writing any actual tests, we need to create a synchronous version, one which can be used by the “async” one, just that it would be on a different thread.

Moving forward with the implementation of the asynchronous alternative for the copy operation, I started designing the tests, only to bump into another issue. Whenever we would copy file X to directory Y, we had the option of renaming it so, naturally, I designed cases for both alternatives. The bigger issue here was if we tried to copy directory X containing file Y into directory Z. Copying X into Z, while changing its name to “T”, would result in Y containing a directory named T (which is fine) aaaaand a file named Z (which wasn’t really fine). This was a flaw in our code, so after a quick discussion on it with my mentor, we concluded that its fine to split tests into two here as well: one where we don’t change any name (so the result would be Z/X/Y) and one where do change the target name (resulting in Z/T/T), only we would comment the second one and flag the issue in order to be worked on afterwards. I opened an issue on it and moved on with the implementation of the test.

Unfortunately, my finals session started so I had less time to work on my project. My mentor was awesome about it and said I should focus on my exams and it would be fine to contribute when I have the time for it. While it’s not final yet, this would be a sneak-peek at the copying test right now which I aim to finish alongside the move one (which I started writing while trying to figure out the new name issue regarding copying I’ve just mentioned above).

I honestly can’t wait to be done with finals in order to work on these. Contributing to to Nautilus, being an active member of its community feels way more rewarding than studying algorithms in uni. 🙂

23rd of April

On the 23rd of this year’s April, the accepted GSoC projects were announced. It was a super stressful day for me and I barely slept on the previous night as I was eagerly waiting for the list to be posted.

I kept checking the official site and my email but nothing would show up! I wanted to know as soon as possible, be it 6 AM! Of course, I still had to wait most of the day for it as I’m on EET and (presumably) the GSoC organisation is not on the same page here.

An university organization which I am part of had a meeting that day which I attended. While different ideas were being tossed around and discussed, I decided to refresh the Google Summer of Code homepage to see if anything’s up, albeit no email had been delivered.

Lo and behold (not as surprising as it was for me considering I am writing this) my project had been accepted and I was about to start my bonding period as an official member and contributor under the GNOME community!

I doubt I’ll soon (if ever) forget the feelings I went through as I saw my name listed there. At first, I could not find myself. The GNOME projects list kept going and going, I even went past my fellow Nautilus GSOC’er project and would not see my name. Eventually, I saw it, “Tests, profiling and debug framework for Nautilus” with  my name on top of it. It just felt both rewarding (as I had been contributing to Nautilus for a while up to that point) and relaxing, knowing I would get to contribute to something I use on my day-to-day work and alongside the people I got to learn so much from, all whilst being a part a of a huge project, whose name is familiar to millions of users.

What followed was 2 weeks of bonding and interacting with the community (which I had already grown fairly familiar to), learning the workflow and getting to know the project and organization even better. Luckily for me, contributing for about 5-6 months helped me with these, so the bonding period felt comfortable.


What’s this fuss all about?

This blog is a place where I hope to talk about my experience as I dive into the world of open-source, picking up a huge project where people take a lot of time to teach me what (maybe) seems to them like the simpler concepts.

I’m excited to learn new technologies and ask a lot of questions in order to polish my knowledge nice and thorough!