I have big good news to share with you. You might know we have been working for years on materializing what we wanted the future of contribution to be, we did multiple iterations and we worked full time on our developer experience… and finally, I’m glad to announce, we achieved it, we have a new way to contribute to GNOME!
One image says more than 1000 words, the whole process of contributing to GNOME is as easy as you will see, all documented in the new newcomers wiki
No specific distribution required. No specific version required. No dependencies hell. Reproducible, if it builds for me it will build for you. All with an UI and integrated, no terminal required. Less than five minutes of downloading plus building and you are contributing.
Can you imagine how this changes the GNOME contribution story? We went from requiring either latest Fedora or Ubuntu, fighting dependencies and random issues, taking more than 80 modules to build just for contributing to a single app. It was a pain.
As an example, Nautilus with the previous tool and workflow took around 6 hours the first time if no issues were present. Now it’s 5 minutes, with no possible build issues (forgive exceptions in the rule 🙂 ).
I think we just opened a new world for contributors.
The work behind it
Of course, a change as big as this didn’t come overnight, this is possible because GNOME and sponsors put the time and resources on it, with rock-stars like Alex Larsson creating Flatpak and Christian Hergert creating Builder, working both for years nonstop in these technologies, with no short term benefit.
Finally the benefit is here, the future we imagined and shaped 5 years ago is coming together, and it’s shining.
Thanks a lot to the people involved, also specially Bastian Ilso for his guidance, design and writing of the new wiki guide.
Hope you enjoy all the work we did, I’m looking forward for your feedback and to fix the issues you may find (contact us in IRC in #newcomers). And soon, to have your first contribution with GNOME done 🙂
PD: Please follow the newcomers wiki to have it working, lot of work to make this happen was done in Flatpak 0.9.1, when Ubuntu 16.04 has 0.8.4 for now, so we say to use a PPA for have it updated. I tested thoughtfully in Ubuntu 16.04 and Fedora 25, and it works out of the box following the wiki making sure Flatpak is updated. Thanks all for the feedback so far! 🙂
PD2: I just realized I had a small error when doing the switch to the new wiki and the instructions for Ubuntu 16.04 and PPA got lost. Now it’s fixed, try again and tell us how it goes! 🙂
Another release of GNOME and Nautilus is coming, 3.24. As we have been doing for every release I will explain the changes that have an impact on the users and explain the reasoning behind them, and also a brief look into what we worked on this release.
Accessing root files – The admin backend
Since Nautilus was created, if a user wanted to open a folder where the user didn’t have permissions, for example a system folder where only root has access, it was required to start Nautilus with sudo.
However running UI apps under root is strongly discouraged, and to be honest, quite inconvenient. Running any UI app with sudo is actually not even supported in Wayland by design due to the security issues that that conveys.
So now we put a gvfs backend (kudos to Cosimo Cecchi) and we added support in Nautilus to open folders and files with no permission to access then conveniently into Nautilus itself. Now if you try to open a folder that requires special permissions it will ask for the root password with a dialog and once provided it will allow the user to navigate them without needing to restart the application or opening a new instance. The password is saved with a timeout so you can use access the file for some time, as is common with PolKit.
Also this allows to use Nautilus to access these files when using Wayland.
Here’s a demo how it works:
Two releases ago we introduced a new way to handle operations in Nautilus, using an integrated popover rather than a separated window. We also added a button that shows a pie chart with the completion progress of the operations.
One issue we faced is that this button was not visible enough when an operation started, making the user think nothing was happening and the operation didn’t actually started.
For that we added an animation that makes the button shine, but seems that was not enough and after going back and forward through some solutions we end up showing the operations popover when and operations started, which is the last resort we could go with.
This is by far the least ideal solution, since it kinda disturbs the user and makes them dismiss the popover in every window (because where do you show it? only in the source of the operation? only in the destination? only where the user is looking at? everywhere?)
So we created a new animation that tries to catch more attention, and we will like to receive some feedback on it. Here is a demo:
And so far we didn’t add any user change more, so it should be a good release for those that like stability.
Nautilus desktop works on Wayland sessions
Thanks to Florian Mullner, he came up with a simple but working solution. Now you can use the desktop when in a Wayland session. Keep in mind this requires XWayland, and it’s backported to 3.22 too.
What we have work on
Flow box view
As you may know, the views in Nautilus are quite old and on the technical side they lack the most basic modern stuff, due to it’s custom implementation. For more than 2 years we have been working on allow a new view based on GtkFlowBox to be created.
Issues with current implementation are:
It’s not using gtk+ widgets or containers. This is by far the most important issue:
Any change or new feature requires a whole “widget alike” object creation.
We cannot use any of the gtk+ widgets technology, including the gtk+ inspector or CSS
We cannot really create new visualisations like a placeholder for when copying files with some progress information or showing tags for files or any smart feature you could think
We have to maintain a big amount of code that Nautilus shouldn’t. This is widget work from gtk+
Spacing between items is not dynamic
Selection of items modify the visual of the picture, videos, icons with a blue overlay
We cannot have several zooms without making the view unusable.
The view and items “jumps” while it’s loading the files inside, making effectively useless to use Nautilus while the directory is being loaded.
This work it’s without hesitation the hardest and longest that Nautilus have faced for years. It required the desktop to be split from Nautilus, it requires modification in the most basic level of the code, porting to new technologies, etc.
Unfortunately, even if we managed to make all of this work, due to its performance issues we cannot switch to GtkFlowBox yet, and more work is required both in Nautilus and gtk+.
However I’m happy to announce that on the Hackfest we did last Novermber we decided to push forward this as a optional view to be able to iterate on its implementation and open the door for contributions from contributors and GSoC projects on it. This work is an experiment in several ways, not only in the technical part but also in the views itself and the code design. We will iterate on the feedback and code to make it shine before making it the default view. The same will apply to the list view once the icon view is ready.
This experimental view is now optionally checked as a gsetting called “use-experimental-views”. It’s not yet in the user preferences because it’s not in a usable state and it’s not intended to be used by nobody other than developers contributing to Nautilus.
Probably most of you already saw how this looks like on some of my posts in social medias almost a year ago. The state now is much better, here it is:
What did not make it into this release
You can take a look at the roadmap of Nautilus to see that most of the items I planned for this release were not implemented. Instead we implemented two different ones, the admin support and the new icon view.
This is expected, we decided a year ago to do a “tick-tack” release pace. Than means, one release with a lot of new changes and one with stabilisation and improvements in mind, and we kept that promise. We needed to stabilise and improve the new features, like the batch renaming and the decompression support, that we added last release.
The reasons this time are different. For the path bar, it was mostly because of the work in gtk4. We don’t want to have different path bars in gtk file chooser and Nautilus. So I would say we need to port Nautilus to gtk4 before committing the new path bar to gtk+. And that requires more work, and to gtk4 to stabilise a little.
For the action bar, was mostly because we need more design time on it. The difficulty in this project is not technical, but design wise.
You can look more details and bug fixes in the NEWS file.
Hope you enjoy the new release! As always, feel free to give any feedback or ask any questions in the comment section of this blog, be constructive please 🙂
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.
Since it’s hard to see what’s written:
System vs apps (containerisation)
Usage app (one is being created)
Control center redesign
System vs user installs
Content selection portal
Bookmarks / XDG folders
Opening files with content apps
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 planet.gnome.org 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!
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.
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!
Kinvolk folks will provide us the venue and snacks every day, thanks!
Collabora will provide us a sponsored dinner the first day, thanks!
And of course thanks the GNOME foundation and Red Hat who will help a big part of travel and accommodation costs.
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.
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
Rename with a template & metadata of files
And a real use case
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
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”
Thanks Razvan Chitu for this work!
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!
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
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.
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
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.
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.
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 🙂 ).
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.
$ flatpak remote-add --gpg-import=nightly.gpg gnome-nightly https://sdk.gnome.org/nightly/repo/
$ 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.
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: