Nautilus team grows – It’s my pleasure to welcome Ernestas Kulik as co-maintainer

Becoming a maintainer of a FOSS project is not easy. It requires much more than just code skills. It’s about responsibility, product management, vision, community and hard work in long-term.

Becoming a maintainer of a FOSS project like Nautilus is even harder, it requires a sense of what being used by millions of people and delivering to business entitles. It also requires understanding the complexity of a file manager, and the old code that lies behind.

Now, becoming maintainer of a project that already has a maintainer working full time on it… that’s a different level.

Ernestas started contributing more than 2 years ago as a community member on his free time. Did major code work like porting Nautilus to Meson, make Nautilus work on Flatpak, improved search, improved operations, took the lead on fixing all deprecations (we had many!), worked on a prototype for a new cache/operations backend, dig into other libraries deeper on the stack to fix something that was visible in Nautilus, and many other things. What was most noticeable is the quality Ernestas strives for in all these contributions.

However, the above would make him “just” a good software programmer, the important part that makes him a good maintainer were other actions. Ernestas took the lead on newcomers bugs review/assignment, took the lead on legal matters like the GPL3 vs GPL2 issue we had with extensions, reviewed code from other contributors (including me), worked without dilation on critical issues in a timely manner, worked on tasks important to our vision, engaged in bug reports with good communication, helped with project direction, considered all sides and the big picture when taking decisions and last, all of this with excellence. If you ever wondered what someone has to do to become a good maintainer/co-maintainer, here’s the answer.

So without more dilation, welcome Ernestas in his new role as co-maintainer, go on IRC and congratulate him ūüéČ

Nautilus desktop plans

Hello all,

We have been discussing our plans with the desktop part of Nautilus for quite a bit of time and in this blog post I’ll explain them.


Nautilus had have a feature called “the desktop” which adds icons on the background of the user workspace, similar to Windows.

The desktop was disabled for the default experience when GNOME 3 came out now 6 years ago,¬† and so far has been mostly unmaintained. I spent around 3 months of work two years ago to try to save it somehow and did a rearchitectural work¬† to try to separate the desktop from the Nautilus app so it won’t affect Nautilus development, and while it achieved some degree of separation, it didn’t achieve its main purpose and unfortunately brought even more problems than we had before. Now it has got to a point where the desktop is blocking us deeply in basically every major front we have set for future releases.

Also we notice that users rightfully have expectations for the desktop to work decently, and we acknowledge this is far from the reality and we are aware that the desktop is in a very poor state.

If you are interested in more technical details of the issues with the desktop implementation you can read them here.

With these points at hand that have accumulated over the years, we are at the point that we need to remove the desktop code inside Nautilus for Nautilus 3.28 to move forward with Nautilus development. You can check the branch with the removal work here, if you look you will see that the desktop is composed by more than 10.000 lines of code given the complexity to create it with the technologies that were available in 1999 (yes, the code is that old :)).


With removing the desktop code from Nautilus we have considered these three options, keeping in mind that the ability to have icons on the desktop can be provided by other projects than Nautilus:

  1. Fork Nautilus desktop, one project being the desktop and the other being Nautilus app. This however doesn’t fix anything at all, the issues will still be there and I’ll be very sad for anyone that has to maintain it.
  2. Use Nemo desktop. This is, as of today, a more featureful desktop than the one in Nautilus, so probably it’s the best short term solution. It however has similar problems than the ones Nautilus desktop faced. You can read how to install it here.
  3. Make the desktop icons a Shell extension.


The best option to of those three to move forward is to integrate it in a GNOME Shell extension. Doing what nautilus desktop was doing in an app (Nautilus) while trying to be part of the compositor (GNOME Shell) was a big mistake, and it’s one of the major issues. It’s important if you understand some technical terms to check the issues we were facing to understand how we agreed to this proposal to be the best option. This is true even more nowadays with various technologies being more in the isolation, privacy and secure side (Wayland, sandboxing, etc).

A nice thing of doing a GNOME Shell extension is that it opens the path to a more dynamic desktop workflow, and the good news is that the prototype that we have in place already has fixed one of the oldest bugs we had in the Nautilus desktop, proper multimonitor support!

You can check the extension prototype here (very early prototype). While this extension is the way forward, the time I can spend on it is limited since upstream wise the desktop pattern didn’t make much sense for long time now. So I encourage anyone that knows JavaScript or wants to learn JavaScript and likes the desktop workflow to make it happen, I’ll be there for helping any contributor making code alongside and to expand on new ideas for the desktop workflow that those that like it have in mind. You can check few points that would be nice to have for a first release here. Ping me on IRC if you are interested on it.

Who will experience a change

For those using distributions with desktop pattern workflows (e.g. Ubuntu), I don’t expect anyone to be affected, if those distributions/projects derived from upstream design decisions based on their own design decisions, I expect they will hold into those patterns and provide a desktop workflow in one form or another.

If your distribution didn’t ship a desktop by default and you were using Nautilus desktop, you can check out the options proposed before to continue using a similar workflow.

Fruits of the removal

The question is, when are the fruits of the removal of the desktop going to be noticeable?

Thanks to the removal of the desktop code we are now free to move forward with the complete rework of the Nautilus backend for 3.28, probably the biggest rework ever done in Nautilus. This will allow heavy searches to not make the UI get stuck and to be resource balanced so you could do multiple searches at the same time, it will also provide proper thread handling, ability to pause operations, ability for performance stats (and finally being able to do performance improvements), easy tweak for operations resource balancing, and more.

Another major work that thanks to the removal of the desktop code we can move forward with is the new views that I talked about in a previous blog post. We won’t make it for Nautilus 3.28 since it requires gtk+ work too, but now we can continue improving it in the Nautilus side and hopefully for 3.30 we can finally move to the next generation of content views.

And finally, this also allows for Nautilus to be ported to gtk4. This is really good news in various fronts for Nautilus; hopefully gtk4 stabilizes a little bit more and we can port to it for Nautilus 3.30.


I want to thank Ernestas and Antonio to work on these big changes and the help overall with Nautilus!

GitLab update: Moving to the next step

Hello community,

I have good news, after few meetings and discussions with GitLab we reached an agreement on a way to bring the features we need and to fix our most important blockers in a reasonable time and in a way that are synced with us. Their team will fix our blockers in the next 1-2 months, most of them will be fix in the release of 22th of December and the rest if everything goes well in the release of 22th of January. The one left that out of those 2 months is a richer UI experience for duplicates, which is going to be an ongoing effort.

Apologies for the blockage for those that regularly asked to migrate their project, I wanted to make sure we are doing things in the right steps. I also wanted to make sure that I get feedback and comments about the initiative all around in my effort to make a representation of the community for taking these decisions. Now it’s the point where I’m confident, the feedback and comments both inside and outside of our core community has been largely that we should start our path to fully migrate to GitLab.

So starting today we move forward to the next step, this means that all projects that want to migrate are free to migrate. I’m also coordinating with some core apps for a migration in the upcoming month (e.g. Documents, Photos, Boxes), with other core projects to be migrated once we have in GitLab the features we need (i.e. Software, Shell, Mutter), and more platform-ish core projects like gtk+, glib etc. to be taken their time to ensure their migration is smooth. All depends individually of the project and the maintainer, of course.

With this change comes other news: We did our first batch migration of 8 projects today, totaling 21 projects that have moved by now. Also, the Engagement team has started using GitLab for better tracking and collaboration with the rest of the community, don’t hesitate to¬†check it out¬†if you want to make publicity of some feature or if you want to collaborate!

To make the transition easier, I created a general documentation for using GitLab for GNOMER’s, check it out¬†here¬†(feel free to edit). If you want to help, get in touch with me or check out our¬†task list. If you want your project to be moved, get in touch with me or create an issue like¬†this one.

As always, I’m there for your questions and feedback. You can do so in this mail chain, in irc, in private messages to me or by filling issues in the¬†GNOME infrastructure project. I just want to ask, please keep in mind that I’m doing this entirely in my free time, so be considerate, I don’t have unlimited energy ūüôā

Also thanks to all that helped so far, specially Phillip, Emmanuele , Alberto, Andrea and the GitLab team.

Hope you enjoy the news and the work we have done.

You can follow the discussion in the desktop-devel-list of GNOME.

GitLab initiative – Short summary

Hello all,

Georges told me some people outside of our community asked about our GitLab initiative and that there is some confusion what the status is and that contrary to my belief, there is actual interest outside of GNOME. Since I guess people outside of our community didn’t follow our regular conversations, discussions and update reports in our GNOME mailing list for general desktop discussion,¬† I’ll do a short summarize.

Almost a year ago we started looking into alternatives to Bugzilla and cgit, and it became a long research, discussion and meeting with several parties and a few of us, Alberto, Allan and me, which then expanded to more people in order to give a different point of vision, like Emmanuele, Daniel, etc. All the research, work and reasoning we did and our eventual decision for a recommendation is written in our wiki page.

The actual status is that we are running a pilot program. The pilot program is a way to test GitLab in real life usage with real products, collect feedback, promote the usage and getting used to the tool by the GNOME community, and eventually to take a decision whether we migrate to GitLab the GNOME project as a whole.

Given the (social more than technical) complexity of moving all GNOME at once to a platform nobody of us used for GNOME projects, we decided to gradually move some willing maintainers and projects first, limiting the amount and the type of projects we migrate. In this pilot program, maintainers commit on a permanent migration to GitLab for the time being, to be aware of the issues we are dealing with, and to provide feedback when possible. When our tasks are done, technical issues fixed, current maintainers in the pilot program give a general positive feedback, community gets used a little bit more to the tool, and the upstream fixes we asked for are done, we will take the decision to move or not to GitLab GNOME as a whole.


Are there deadlines?

No. And at the same time, ASAP, which for a project of our magnitude is in the range of months.

What are you blocking on?

In tasks on our side, and in upstream issues. And of course, in our energy and time.

Can I help?

Yes, feel free to ping me for those task on our side.

Where is this hosted? Which projects moved?

You can take a look on our GitLab deployment.

Who is the person of contact/Who is taking most of the decisions?

Nowadays mostly me, with our sysadmin Andrea on the sysadmin side. I’m trying to represent as much as possible GNOME as a whole, and I’m focusing on trying to evaluate how much the community is happy with it or what has more or less priority. Obviously, this is the hardest part.

When will a decision be made? What are the requirements for that decision to happen?

This is more a social problem than technical. It needs to settle down on our community and is difficult to quantify. So no deadlines, and no hard requirements. As mentioned before, I’m trying to evaluate the consensus of the community and the overall status, and I’ll communicate to the GNOME community when I think a decision can be made and what I believe we should do, and get feedback at that point.

What’s the worst case scenario? How likely is that to happen?

The worst case scenario is that we decide we don’t move to GitLab as a whole, and then I expect the projects that migrated to GitLab to be migrated again to Bugzilla and cgit. There are other possible scenarios, but I don’t consider them for now. At this point this¬† scenario is unlikely to happen, since the initiative is going better than expected and I receive more queries to move projects that I can manage or that I consider we should migrate for now, the feedback in overall is positive and there is excitement in core maintainers and products to move to GitLab.

It’s true we have some blockers upstream that we are tracking in our instance¬†as mentioned before and that they need a solution to move forward, but I’m confident with our meetings and discussion with GitLab eventually they will be fixed.

I have feedback/other questions/issues

General feedback can go to our wiki page or for public discussion. You can also contact me on IRC as csoriano in #gnome-hackers at or send me an email to for direct contact. Issues can be reported in our GitLab itself.

Empowering individuals of the community – The board takes action

(Disclaimer: I’m speaking as a single director of the board, wording and specifics could be different than written here as this post has not been reviewed by the board.)

(Disclaimer 2: Some parts of this blog post were covered by¬†Allan’s and Alexandre’s blog posts.)

This blog post is intended for GNOME Foundation members or people interested in part of our budget management. I have good news for you, the board has decided new policies to empower the individuals of our community!

Budget for individuals

For long the board have been the holder and decision making approval of all (big exception with travel committee) the GNOME foundation budget. Of course the community trusts the board to manage the budget as the board believes is better for GNOME, but the board thinks GNOME members doing important work for GNOME are also to be trusted, and we need to empower them however we can.

In order to achieve this, the board has approved a new policy. Now, individual GNOME members can be holders and managers of budget!

That means, as a single GNOME member you can be given an allocated amount of cash to be managed and spent in the way you believe is better to progress the goals of GNOME (after budget and goals are discussed and pre-approved with the board), and you will be able to spend this amount of money per year without need to discuss again with the board, or any other approval. That could include things like buying items or food for a meeting, promoting other individuals (a wild idea, for example to bring an expert to a workshop), promoting small events with marketing, etc.

A concrete example: You could mention to the board that you usually host workshops for newcomers and workshops for translators in your city. Then the board allocates 500$ per year to be managed by you for this purpose. You don’t need to discuss or pre-approve anything else, you are free to spend that budget yearly with that intention indefinitely, we will just look at the reports to see how things are going or do some meetings to sync with you.

I’m honestly excited imagining all the possibilities that this brings to members of GNOME, and how much that empowers the individuals of our community. Wanna know more? Read the budget policy for individuals.

Delegated decision making

We talked about budget management. But the board is also responsible of most of decision making at GNOME. Marketing, events, conferences, sponsorship, hardware requests, the software that defines GNOME, legal inquiries, and many more. However, we believe members of the community should be trusted to also take part of some high level decision making of GNOME.

We want the community to take leadership roles, influence where GNOME goes, and give them voice and decision making power. We want more integration with more people of the community. In short, we want members to take the role of the board in specific topics. A step closer to the board itself.

So the other big decision is that the board have agreed on expanding this concept, reach more community members and promote new roles to take upon. To achieve this we have started drafting new committees with new members, an approach to be more in touch with our current and new committees, and brainstorm a way to make easier for members of the community to apply for these roles.

This is still not set in stone and we are looking for other ways that are not necessarily committees, or to make some committees more flexible & easier, but I hope you are ready because we will write over the next weeks news about this and opportunities for being part of them!

Thanks the board and foundation employees

As a selfish last section, I want to thanks all the members of the board and employees. This wouldn’t be possible without their energy and tireless willingness. These discussions were part of our hackfest at Berlin; honestly, the hackfest was hard and draining, but it was productive and necessary. It was the first time in the history of the foundation that the budget was approved at the start of the fiscal year, so I’m proud of what we have achieved. Many more discussions, decisions and policies took place, you will heard about them over the next weeks.

Like what we did? Let us know!

Hope you like the work we have been doing, the policies and ideas we came up with to empower you as part of GNOME. I also hope you now have a grasp of what the board does and how it can impact our community.

If you have any question, let me know here, irc or by email, I’m looking forward to know what you think. You can also always contact the board at, don’t be afraid of it, really!


PSA: All newcomers apps build again

For some time a few of our newcomers apps were not building due to an issue with Builder and Flatpak.

Finally the issues are fixed, in Flatpak 0.9.10 and in Builder stable (that you will have from Flatpak if you followed the Newcomers tutorial). Only thing needed is to update Builder and make sure Flatpak is at version 0.9.10.

If your distribution has already latest Flatpak (e.g. Fedora 26 or newer) and GNOME Software 3.24 (e.g. Fedora 26 or newer) you simply need to go Software, click the refresh icon, wait to download updates and then click “Update all”.

If you want to do it in the command line:

flatpak update
flatpak update --user

And to update Flatpak in Fedora

sudo dnf update -y

Apologies for having broken builds of Newcomers apps, we definitely need a way to ensure Builder integration with apps are tested regularly in the future!

Feel free to report if something is not working as expected in our newcomers channel.

Remember you can start contributing to GNOME apps and technologies in a few minutes following our newcomers guide, give it a look!


Hello all!

One thing I enjoy to do when visiting a new city is to visit corners that are not touristic to not miss the “real” culture that you can experience in non-touristic places.

Not only that, but we all know¬†we are used to¬†eat more than usual when traveling, and we don’t keep doing some of our good habits.

For that reason, every GUADEC¬†I try to put together some people and we go running for 5-7 km to different places every morning, with¬†optional exercices once finished. It’s exercice to chill and enjoy, so no worries if you are not in shape.

I created a Riot room that you can access (even as a guest user) through the web, phone, etc. to discuss where we will meet and where we will go

So make sure to bring your sport shoes, don’t be lazy, and join! ūüėČ

Clarification on a recent security flaw on a thumbnailer

Recently a GNOMEr pointed me to a blog post from someone that found a security issue with a thumbnailer called gnome-exe-thumbnailer which tries to thumbnail MSI files and parses VBScripts using Wine, and unfortunately it allowed execution of random code.

How thumbnailers works is that we allow libraries to register as thumbnailers to be used by our generic thumbnailing framework, and although they are out of process, they are not sandboxed. You can understand this issue as if it would be a plugin that has a security flaw.

This would have been a regular CVE in gnome-exe-thumbnailer and world would have move on, however the problem came when the author pointed out the fix was “Don’t use GNOME Files” and the framing of the blog post was, from my point of vision, misleading.

In reality this affect anyone using this thumbnailer, including MATE, XFCE, etc., the project has nothing to do with GNOME, we have never heard of it, and some distributions don’t even have it in their repositories (in this case I checked RHEL and Fedora and they don’t have it). I also find quite disrespectful towards whoever wrote that library to not raise a bug privately, and instead made a public blog post.

The CVE in question, named “Bad Taste” (with even a logo(!) of a wine glass)¬†can be found here.

Does this affects me?

Probably not, since you would have need to install this library on purpose and also use a distribution like Debian/Ubuntu (so far what I checked) that includes it.

However be careful if you do since quite a few programs would use that thumbnailer, including Totem, Eye of GNOME, etc. and there is no way to disable thumbnailing on those (ironically Nautilus does allow to disable thumbnailing).

The fix

Uninstall gnome-exe-thumbnailer :). You can still use Nautilus.

Can GNOME do something?

Yes. We can sandbox thumbnailers (with the same technology as Flatpak, called bwrap). Work is actually almost done over the last 6 months, and hopefully will be merged and relesed soon.

This is also a reminder to all of us that we should move to a world of more sandboxed applications and plugins. This is actually one of the top priority items for us. In that front we have been working hard and pushing as much as we can with Flatpak to create a world of sandboxed apps. If you are interested on the security side of applications, you are welcome to help us shaping the future of it.

In conclusion, it takes 2 minutes to contact any of us and verify your statements/blog post/tech news. Please do, before posting.

As a take away, grab this mojitoūüćĻ¬†and fix the “Bad Taste” ūüėČ

The new contribution workflow for GNOME

Hello community,

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! ūüôā

PD3: Cool video of Jono Bacon showing what Endless does with the same technology

Nautilus 3.24 – The changes

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.

User changes

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:

Operations button

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.

So¬†actually there are the same items that couldn’t be included and were mentioned in the previous release blog post.

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 ūüôā