Core Apps Hackfest – A success!

The GNOME Core Apps Hackfest just finished, I’m happy to say that it was a success!

Many people from different backgrounds were able to come, either from the community or from companies like Red Hat, Endless, Kinvolk, etc. all of us involved in different parts of the GNOME project.

The first we did was to write down what points  must be discussed during the 3 days, along with identifying the people involved in those topics. This was the trick to be productive in the hackfest, and all of us agreed it worked.

first day hackfest.jpg
First day early in the morning, before all people joined
Roadmap for the hackfest

Since it’s hard to see what’s written:

  • Tracker
    • System vs apps (containerisation)
    • Performance
    • Removable devices
  • Maps
  • Usage app (one  is being created)
  • Control center redesign
    • Network panel
    • Details panel
  • Calendar
    • Week view
    • Recurring events
    • Location checks/sugestions
  • Books
  • Software
    • Categories
    • Offline experience
    • Rollback
    • Shell extensions
    • Performance
    • Flatpaks installation
    • System vs user installs
    • EULA/Licenses
  • Sharing portal
  • Content selection portal
  • Libgd
    • Flowbox view
    • Tagged entry
  • Background apps
  • Files
    • Action bar
    • Bookmarks / XDG folders
    • External devices
  • Opening files with content apps
  • Extras
    • Music
    • Videos (series view)
    • Newcomers initiative, new revamp planning

Quite a lot! From that list we identified the most important items and the optional ones that are short enough to allocate some time for. We also identified which items require the most amount of people from different backgrounds to be together so they can be handled as best as possible.

Some topics were very well covered. GNOME Software is now important for a few companies and distributions, so it took quite a lot of discussion during the hackfest . Another topic that was discussed extensively was opening files with content applications, basically using Music, Photos, etc. to open files from Files.

But we also discussed more technical items, thanks to having gtk+ maintainers in the hackfest we were able to talk about gtk4, it’s new OpenGL based drawing model, containers API, GtkListBo, GtkFlowBox and essentially all what we need for our applications and 3rd party developers in the upcoming months.

Some of us will write about the specific items in the upcoming days with blog posts, so keep an eye on to see all the discussion we had and what solutions and decisions we came up with for those.

I want to say a big thank you for the excellent organisation of Joaquim Rocha, and for hosting us to Kinvolk, especially to Chris Kühl


and Collabora for sponsoring an excellent dinner on the first day of the hackfest


We had a great one!

Relaxing a bit in the Collabora sponsored dinner

Also to Red Hat and Endless for sending quite a few employees, and last but not least, to the GNOME Foundation for sponsoring the community members, who were essential in our discussions.

Hope you had fun!

GNOME Core Apps Hackfest – Sponsors

As I mentioned in my previous blog post we organized a hackfest to discuss all about the core GNOME experience, with emphasis on core apps and taking into account its impact in 3rd party developers too.
But you can imagine, bringing together a not small amount of developer, designers and community in a single place involves travel costs, accommodation, an appropiate place where we can gather and discuss with internet and tables… and apart of that, small details that improves the overall experience like snacks and something to distract ourselves after a long journey, like a simple dinner all of us together.

This is not possible without the GNOME foundation and companies who believe this is important enough to sponsor people going and the organized events.
In this post I want to announce and thanks the (so far) two sponsors we have got already!

The sponsors

Kinvolk folks will provide us the venue and snacks every day, thanks!


Collabora will provide us a sponsored dinner the first day, thanks!

Collabora-Logo (1).png


And of course thanks the GNOME foundation and Red Hat who will help a big part of travel and accommodation costs.

Hope to see you all there!

GNOME Core Apps Hackfest

It’s official now, we will have a GNOME Core Apps hackfest happening in Berlin, Germany on November 25-27!


The hackfest is aimed to raise the standard of the overall core experience in GNOME, this includes the core apps like Documents, Files, Music, Photos and Videos, etc. In particular, we want to identify missing features and sore points that needs to be addressed and the interaction between apps and the desktop.

Making the core apps push beyond the limits of the framework and making them excellent will not only be helpful for the GNOME desktop experience, but also for 3rd party apps, where we will implement what they are missing and also serve as an example of what an app could be.

In case you are interested, here is the wiki page with more information. All of you are welcome to attend.

Thanks to Kinvolk folks that will host us in their office!

Nautilus 3.22 – News & Changes

Nautilus 3.22 is reaching it’s final phase, and as I have been doing in the past, this post will explain what new tools and improvements we worked hard to implement, what changes to expect, and what we couldn’t fit in. I need to confess I’m excellently amazed with this release, it has so many new things that I’m proud to say this is the best release we did of Nautilus since I became maintainer. This is possible thanks to all the underneath work we have been doing, and sometimes this requires the removal and re-implementation of some tools in a different form.


Lets take a look what we included in this release

Multiple Files Renaming

For some time users of Nautilus lacked a tool for rename multiple files at once. We relied on external tools or command line utilities. It’s true that other file managers had utilities for multiple files renaming for long time, including Finder from MacOSX. Thing is we weren’t happy with how those worked and the experience they provide. So we designed and put lot of though on making, in my humble opinion, the best batch renaming tool we could have.

We allow to use the metadata of the files when available, which is for me the biggest win in our tool. I’m happy I could rename all my music files using the track number, album name and track name. Same for TV shows, where you can add the season and episode. And for pictures, the camera and the date taken.

A picture worth 1000 words

Search & Replace

batch rename3

Rename with a template & metadata of files

batch renaming1

Conflicts handling

batch renaming2

And a real use case

batch rename music

Finally my music library renamed with the same pattern! I think you will agree with me this is pretty amazing. Thanks Alex Pandelea for this work!

Compressed files integration

You may be aware that we have been using File Roller since forever to handle compressed files. However, this makes integration with Nautilus none. It misses the progress report integration, undo, redo, and possibility to close the application while the operation continues. Finally we tackled this, it was a big amount of work where we needed to create a new library to handle compression and decompression in a way that can be integrated with Nautilus and other GNOME projects. For instance we would like Evolution and Epiphany to automatically compress/decompress archives on upload/download. Using this library, called gnome-autoar, is pretty simple.

Again, a picture worth 1000 words, let’s look at compression dialog

compress window.png

We provide a sensible set of options. Now let’s take a look at compression progress integration.


We finally have status report, undo, redo and operation integration like any other Nautilus operation!

The same applies for decompressing. Overall, this is something we have been pursuing for years, and the output is pretty cool. This allows us to finally be able decompress archives by default when double clicking on them, so the user doesn’t need to handle compressed archives, which usually provide much less information like thumbnails etc than a regular folder. In case you still prefer to use file roller or any other application by default to manage your compressed files, we added a preference in the preferences window.

Here you can see the option “Extract the files on open”preferences.png

Thanks Razvan Chitu for this work!

View menus

As you may be aware, we perform user testings regularly. In the last user testings  was found that the view menus of Nautilus had some issues that could be improved for a better UX experience. The design team put some though into it and came with a design that fix these issues, and Neil Herald implemented them. Here are the results


Now the grid/list button changes between the two kind of views, and we merged and improved the hamburguer menu to include all the options we wanted. The zoom slider was one of the most fails in the user testings, so we took a similar approach of what Firefox has.

I’m quite happy we fixed the user testing issues we found every release!

Separate desktop handling from Nautilus

There are two monsters on Nautilus. One is the operations handling, the other, the views.

Since I became maintainer of Nautilus my top goal was to re-implement the views of Nautilus to provide what we should have in a modern file manager. This requires an amount of work unimaginable, and part of that is because Nautilus handles the desktop window, which is made by several amount of hacks all around Nautilus to make it work. This needed to be split before any work can be started on the views part, and it is not easy. We started one year ago, and I’m happy to say, this release we finished the work on the Nautilus side, separating the desktop program and code from regular Nautilus. Now if the desktop crash, Nautilus won’t. This allows us to finally implement a modern and responsive view for your files!

This is a peek video at the view I prototyped thanks to this work


However, this requires also work on Gtk+ for improving the performance, which is what we are going to try to tackle next release. More than half step is done!

Better folder creation from selection

This is a small touch, but I think worth mentioning. When selecting multiple files and creating a folder with them, we will search for a common prefix and use that as default name. Here is a picture

new folder

Thanks Neil Herald for working on it!

(Updated, I forgot!) Hide floating bar on mouse hover

The floating bar is what is shown in the rightmost lowest corner of Nautilus with information. However, that can get in the way if the information is displaying is long and obscures the actual content of the view. For that, we implemented a new behaviour that makes the floating bar disappears if the user hovers it with the mouse.

with floating bar
Mouse not hovering floating bar
withouth floating bar
Mouse hovering floating bar

What we couldn’t include

As always, we want to put into a release as much as we can, but we are still humans 🙂

There are two important items that weren’t possible to include in this release.

Action & Info bar

One is the action-info bar we have been experimenting with. We didn’t include it because we weren’t sure about the design and implementation. However we can peek at the prototype

action bar.png

We will continue experimenting in the next release.

Thanks Georges Stravacas for working on it!

New Path bar

The path bar is the widget in the top of the Nautilus window that shows the path, and allows to interact with the hierarchy of the current folder where the user is. We have been trying to update it with a more sane code and elegant design. I have been working on it and iterating through almost 4 different designs for one year and a half.

After all the experimenting, we finally decided on a design!


However, there are technical limitations in the Gtk+ toolkit for make it work in the way designers imagined. So this has been an experiment for me and towards Gtk+ to push its limits. Finally I found a way to make it work, but all the nice projects I mentioned previously came in.

I’m sad I didn’t manage to include it in this release. On the other side I’m happy that we have a prototype and that we will have more time for testing and reviewing.

If you want to take a peek, here is a video demo

Wrapping up

There has been a lot more into this release, from small tweaks to big refactorings and bug fixing. We even created a single code style for Nautilus (it had a mix of 3 styles) and (be careful it might crash your browser) changed all the files to it, which was a demand from all the regular contributors. (edit: please don’t argue about this, the style is agreed by the ones that work on Nautilus every day that makes our performance and life better. Just a matter of practicity. Nothing more, nothing else 🙂 ).

Old style
New style

For this release we have around 900 commits and five regular contributors, which I want to thank one that has not been mentioned here, but it does all what we really need in the places nobody dare to, you rock Ernestas Kulik.

If you want to try last version with updates every day and parallel installable to not affect your installed Nautilus, take a look at the Flatpak installation of latest Nautilus.

Hope you like what we have been working on and enjoy it!

The future is here

To see the future, run in a terminal:

$ wget
$ flatpak remote-add --gpg-import=nightly.gpg gnome-nightly-apps

$ flatpak remote-add --gpg-import=nightly.gpg gnome-nightly
$ flatpak install gnome-nightly org.gnome.Platform master
$ flatpak install gnome-nightly-apps org.gnome.Nautilus master
$ killall nautilus # No running instance has to be present
$ flatpak run org.gnome.Nautilus

*for Ubuntu look at the end of the post.

Results in:


Nautilus from master, updated everyday, parallel installable, in less than 3 minutes. I cannot believe this is possible. Note that due to be sandboxed with no permission handling there are things that are not working, like opening with an application.

For someone not aware of the whole platform and the Linux desktop, it’s difficult to see how many implications this bring to us and the changes that will allow in the upcoming months. This truly changes the game for GNOME (and any other desktop) as a project and platform, including 3rd party developers and companies using Linux desktops or that want to support it.

Amazing job Alex Larsson!  Flatpak is the big step we needed.

In case of using Ubuntu, flatpak is still not in main repositories, it should arrive soon. In the meantime do:

$ sudo add-apt-repository ppa:alexlarsson/flatpak && sudo apt update && sudo apt install flatpak

And then run the commands at the start of the post.

Contributors to Nautilus

At GUADEC Andre Klaper made a report of top most contributors to GNOME in the last year, and to my surprise I saw my name in the top 5 of patch reviewers. Did I really review so many patches?

If you remember I did a blog post stating how healthy Nautilus development is being lately. However I didn’t know it was at this level. And now I also understand why I spend less time coding these days.

To summarize, the first year as maintainer of Nautilus I reviewed around 100 patches in total.

And this is how it looks this year


567 patches reviewed! Almost 6 times more than one year ago. Those patches come mostly from the 5 contributors I mention in the previous blog post. I’m glad they keep contributing to Nautilus, and doesn’t look like they want to go away.

Some of those contributors gained enough experience to help me with the project as a whole, discussing with other contributors improvements on the code, triaging in Bugzilla and reviewing patches. In this a big thanks goes to Ernestas Kulik, who is doing an amazing job and a great help to me in the parts I most need. And of course my GSOC minions Alex and Razvan who I had an amazing time at GUADEC with 🙂 .

Related to this, I asked on the Nautilus BOF at GUADEC what makes contributing to Nautilus interesting for people, and why they keep doing it. I was surprised to know that all of them agreed that most part of it is not the actual code, but our relationship in the channel and the small community we created inside the Nautilus project. Being responsive to the patches contributed and being present on the IRC channel for questions and random small talk makes the whole experience much more enjoyable. Chatting in the channel while coding to Nautilus became a “one beer with friends” time.

I feel the project is indeed moving in the right direction.

Thanks all!


Guadec – Visit Karlsruhe doing sport

One of the things I miss when going to Guadec is to visit the actual city. Usually we don’t have much time for visiting the place, and even if you do, you will visit just few well known places, and more like a tourist rather than a regular citizen, which in my opinion misses part of the beauty.

Another thing is that during this week is common to over eat and break the sports habits you could have.

Last Guadec at Gotenburg I had the idea to fix both problems at once. How about go running, in a relax pace, for about 30 min to different places every day of the conference?

This allowed me to really know the city, and discover few interesting not so well known places.

I will start on Saturday 13 August on the morning before the conference starts, so we can have the afternoon free to enjoy with people and beers.

If you want to join, contact me or join the telegram group @guadecsport or go to and we can set up time and place to visit, proposals are welcome 🙂

Hope to see you!

BOF session of Nautilus – GUADEC


As the tittle says, we will have a discussion/bof session about Nautilus in GUADEC.

As you may know, discussing on internet is rarely a great experience, with the big disadvantage that influencing people over it doesn’t work well. From a developer point of view, I don’t know to who I am talking with and why, so in projects where discussions are a daily experience is difficult to know what we should put on the top priority list.

The small hackfest is going to be focused more on the philosophical side, with specific actionable items for the future.

We will talk and discuss about what we have done wrong in the past; what users are missing, like dual panel and type ahead search, why they are missing it and how we can improve those use cases; we will also talk about the transition from Nautilus 2 to Nautilus 3 and what we can learn from it in order to make changes a smoother experience.

The program is here. I will gladly add anything people would like to talk about.

If you ever wanted to influence Nautilus, this is your opportunity, come to GUADEC.

Do not use comment sections to discuss them 🙂 just grab your backpack and come to GUADEC.

Batch Renaming – Call for design ideas


Alex Pandelea has been working on batch renaming for Nautilus. So far we though about taking most of the design ideas from what Finder, the file manager of MacOSX does.

Here is a video of Finder’s batch renaming

However, after trying a prototype implementation following Finder, I have been changing my mind about the design being good enough.

Let’s take a look at Finder’s design and find the ugly parts.

First mode, “replace text”


I can see few issues:

  • The “Replace Text” combobox doesn’t really provide me a hint that it’s a combobox for changing modes. It looks like part of the mode itself, doesn’t give a hint about having more importance than the entries under it or the cancel and rename buttons
  • The cancel and rename buttons are at the same level than the example and information. I would prefer to have the information and example in one line, then the final decision about cancelling and renaming apart of those. This is now usual in dialogs on the GNOME HIG where the dialog buttons occupy the whole width and are in a different line level.

Let’s change the mode. “Add Text”


One big issue here, suddenly the entry and combobox for the mode is in the same line as the combobox to change the mode. I guess they wanted to give a connection between the UI items in there, so it makes a sentence like “Add text …. blah blabh…. after name”. But that is not the case in other modes, so it’s more confusing than anything.

Next mode is “Format”


And this is the one with more UX issues in my opinion. It has the ones of the first mode plus:

  • There is no visual connection between the “Name format” and “Start numbers at”.
  • “Start numbers at” is only useful for “Name and Index”, not for other name format modes, still it’s there for other modes.
  • It’s using combobox for just three and two options… which is kinda useless. It’s better to just present all the options. Much straightforward, much clearer, one click less.
  • The labels “Name format” and “Custom format” are misleading. Either I want a custom format or something else.

Apart of these issues, I also noticed it doesn’t give you feedback if some file in the directory conflicts with the names that are going to be generated beforehand. We want this on Nautilus.

So I came up with this draft as my idea to cover these issues (my drawing skills are not the best). Note that the mode selected is”Format”, which is the most complex UI wise:

batch renaming mockup.png

I would like to know your thoughts about this, and even better, engage you on providing design and ideas. Now it’s your turn 🙂

Here’s the svg of the picture above,  you can modify and put your ideas

Nautilus & Gtk+ status – 1 year of progress


Today I was having a rough time thinking on how to implement the new GtkPathBar, which is taking more time and frustration than expected given some technological limitations on animations in gtk+ and that responsive design is technologically hard to do.

In the middle of these thoughts, I realized that I was actually discussing these big plans about responsive design for gtk+ with Georges Stavracas, my former GSoC student. I was actually discussing with someone big plans about Nautilus and gtk+. I couldn’t do that 1 year ago, because Georges was not there. Although Cosimo, previous main maintainer of Nautilus, is *always* there if we need him and he reviewed/helped with high impact changes, but he is involved in multiple projects and I personally don’t want to take much of his time.

That made me think about the progress in contributors and technology that Nautilus and gtk+ has made in 1 year. And realized how much it changed, and how good it has become.

In one year Nautilus went from 1 main contributor, me, to 5 regular contributors. That’s really impressive! Not only that, two of these regular contributors are going to be GSoC students this year for Nautilus, congrats Alex and Razvan!

These contributors are random people that got attracted by Nautilus and GNOME and all the plans we have for the project, and I believe we all agree we are having fun chatting around in #nautilus IRC channel, which kinda helps :). They have some specific areas that they are more expert with, and I ask them to review small patches or to discuss some ideas I had for those areas, and usually, my ideas need notorious adjustments, and my patches, changes in the code.

They triage bugs, fix crashes, improve small details all people complain about, do performance improvements, etc. Just today one of these regular contributors improved the copy operation of files in the order of ten times.

No one can imagine how good is for a project like Nautilus to have different developers contributing and reviewing both code and ideas. For one year, I was doing changes freely, and that, even if I try my best, it’s not ideal.

This applies to gtk+ as well. As said, with Georges we share similar areas of responsibility in gtk+, and we discuss and push together for plans we believe are good for the toolkit, so we became contributors to gtk+. Also, it’s important to highlight that gtk+ improved exponentially in the last year, and we have a much more consistency in the code,  that will eventually allow all the big plans we have planned for gtk+, like animations, responsive design, etc.

In conclusion, as far as I can see the development status of Nautilus it’s in its best moment since it was created, and part of that is thanks of the status of gtk+ development and the values and vision of GNOME as a project.

The day ended well after all.