An awesome experience!

GUADEC has been a week full of memorable moments. As my friend Rares mentioned in his post, our  newcomers group was welcomed by friendly community members right as we arrived at the hotel. For someone who has never attended a similar event before, this really helped with getting into the conference atmosphere.

In the first couple days of the conference, I found myself meeting a lot of people that I knew from IRC. It felt really nice to finally know the person behind the internet nick. I was especially excited about  getting to meet my mentor, Carlos Soriano =). In between the presentations I also took the time to prepare my own lightning talk about compressed files in Nautilus. Speaking in front of the GNOME community for the first time was a unique experience.

Of course, GUADEC had a loooot of fun stuff. Playing picnic games like children (and losing them to actual children!), going on ziplines with project maintainers and a little pool party for the Nautilus team, these all added up to a memorable experience. And there were also beers and tequilas, but I guess this is not the place to talk about them :D.

Los tres amigos de Nautilus managed to do some actual work too, polishing what was done so far during the summer. Reviewing and arguing is definitely more fun in person than it is on IRC and bugzilla. By the way, support for compressed files is up and running in Nautilus master and Carlos did a great job on making it available in flatpak, so give it a shot if you’re curious!

So that’s it for this GUADEC. I can definitely say it’s an experience I want to repeat and hopefully I’ll be able to attend and see you all again next year in Manchester!



Internal compression

My project continues with support for internal compression in Nautilus. The operation comes with integrated progress feedback and support for undoing and redoing. Also, the new archive will be automatically selected once the operation is complete. The feature is available from the context menu, where the menu item from file-roller’s extension would normally be:


Since this operation is functionally similar to “New Folder with Selection”, we chose to make the UI for it similar as well. However, we ran into a little issue as we could not decide how to offer compression format options. These are the ideas we came with:

Combobox / List of all available formats


Radio selection, as suggested by Allan Day

Trading supported formats for UI simplicity has proved to be a touch choice. Even so, would users actually use most of the formats displayed in the first version? Would they be fine with having only 2 or 3 options available? Would it be acceptable to use an archive manager for the other options? These are the points that have been debated for the past few days. Feedback and suggestions on the matter are even more appreciated now, as they could really help us decide which way to go!

Well, that’s about it for compression and for this part of integrating file-roller into Nautilus. Looking forward to GUADEC where I hope to see and meet as many of you! 🙂

Automatic decompression of archives

With extraction support in Nautilus, the next feature that I’ve implemented as part of my project is automatic decompression. While the name is a bit fancy, this feature is just about extracting archives instead of opening them in an archive manager. From the UI perspective, this only means a little change in the context menu:


Notice that only the “Open With <default_application>” menu item gets replaced. Archives can still be opened in other applications

Now why would you want to do this? The reason behind is to reduce working with files in a compressed format. Instead of opening the archive in a different application to take out some files, you can extract it all from the start and then interact with the files straight away from the file manager. Once the files are on your system, you can do anything that you could have done from an archive manager and more. For example, if you only wanted to extract a few files, you can just remove the rest.

One could argue that extracting an archive could take way longer than just opening it in an archive manager. While this can be true for very large compressed files, most of the times the process takes only a few seconds – about the same time it takes to open a different application. Moreover, if you just want to open a file inside the archive manager, the manager will first extract it to your disk anyway.

This might be a minor change in terms of code and added functionality, but it is quite important when it comes to how we interact with compressed files. For users that are not fond of it, we decided on adding a preference for disabling automatic decompression.


That’s pretty much it for extraction in Nautilus. Right now I’m polishing compression, so I’ll see you in my next post where I talk about it! As always, feedback, suggestions and ideas are much appreciated 🙂

Extraction support in Nautilus

The first feature added to Nautilus as part of my project is support for extracting compressed files. They can be extracted to the current directory or to any other location. The actions are available in the context menu:

extract_context_menuNow you might be wondering, why add these to Nautilus if they look exactly the same as file-roller’s extension? Well, handling extraction internally comes with a few changes:

  • improved progress feedback, integrated into the system used by the rest of the operations
  • fine-grained control over the operation, including conflict situations which are now handled using Nautilus’ dialogs
  • and probably, the most important change, extracting files in a way that avoids cluttering the user’s workspace. No matter what the archive’s contents are, they will always be placed in a single file or top-level folder – I’ll elaborate on that in a moment.




As I mentioned in my first post, the goal of this project is to simplify working with archives, and creating just one top-level item as a result of an extraction really reduces complexity. It is done in a pretty simple way:

  • if the archive has a root element and they have the same base names (like which contains image.png or a folder named image/), the root element is extracted as it is
  • if the root element has a different name or the archive has multiple elements, they are extracted in a folder having the same name as the archive, without its extension

As a result, the output will always have the name of the source archive, making it easy to find after an extraction. Also, the maximum number of conflicts an extraction can have is just one, the output itself. Hurray, no more need to go through a thousand dialogs!

If you have any suggestion or idea on how to improve this operation, feel free to drop a comment with it! Feedback is also much appreciated 🙂 See you in the next one!

GSoC 2016: The adventure begins

Hello! I am Razvan, a technology & open-source enthusiast and I am working on what is probably the most interesting project for me so far, Nautilus. So far, this has been the highlight of my experience – lots of interesting things learned while coding and a great interaction with the community. This is mainly thanks to Carlos, captain of Nautilus, who always finds the time to help me and other contributors whenever we get stuck. On top of this, the funny chats with him and people from the GNOME community make contributing so much more enjoyable! Up until now I’ve been titled King of the TrashI’ve learned about some file system magic from Christian Hergert, and I’ve also been threatened by a katana-wielding GNOME samurai. Awesome, right?

For this summer I will be taking my contributions a step further as part of the Google Summer of Code program. The project I will be working on is integrating the default archive manager in GNOME into Nautilus. This idea in particular has a special significance for me, since it is what I first wanted to do when I came across Nautilus. Getting the chance to do this as a summer project is just amazing!

The goal of this project is to simplify working with archives by integrating the core features of file-roller in Nautilus, making decompression the default action for when opening a compressed archive. Alternatively, navigation through the compressed file like a normal folder would be possible as well. Compression and decompression will be handled internally by Nautilus using gnome-autoar, a library for automatically creating and extracting archives.

Compression and decompression need to become a transparent process to the user, minimizing interaction with archives. In the vast majority of cases, compressed files are just an intermediary point between the user and actual content. The user should have full access to this content right from the start, rather than being given the indirect means available now (for example, file-roller selectively decompresses files and stores them in a hidden cache). Also, since dealing with archives is actually dealing with files, the user should be able to do this from the file manager.

From the developer’s perspective, moving archive support to a library will allow for compression and decompression to be handled internally by applications. This should reduce the usage of file-roller so it can eventually be removed as an application.

With these goals in mind, there’s just one simple step left to do: coding it! and coding it well. There will be more posts from me detailing my progress, most likely every time I hit a milestone (or when I gloriously crash everything). Until next time!