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.

2 thoughts on “GSoC 2018 Final Evaluation”

  1. Great work and insightful summary, Alex!

    While this work is not directly visible for users, it will help us detect and fix bugs before reach distribution, which is a major improvement in quality.

    As a fellow contributor to nautilus, I’m very glad to see the fruits of this GSoC project and to have you in the team.



    1. Thanks a lot for the kind words, António!

      As I said in the post, testing is something we wanted to do for quite some time and still needs some work. More or less, I’d say the committed patches should help (especially newer) contributors detect some of their errs!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s