Porting Files to GTK 4 has been helping me learn and appreciate even more the legacy of the nautilus software package. Its two-decades-long history is closely entangled with the history of the GNOME project.

As I prepare to merge the removal of more than 20 thousand lines of code, I’ve decided to stop and pay some tribute to the legacy widget that’s about to be decommissioned.

Living legend

The day is May 27, 1998: the day before the start of the Fourth Annual Linux Expo. Federico Mena, co-founder of the GNOME project, uploads a work-in-progress version of the GnomeCanvas widget. This widget would then be included in an “Initial revision” of nautilus as the basis for its icon view.

Screenshots from Eazel website, preserved by the Internet Archive.

Federico’s 1998’s TODO list is still found, more than 23 years later, in the nautilus source code.

Die-hard icons

At some point renamed/forked to FooCanvas and later EelCanvas, this base widget continued to serve as the fundamental base for the GNOME desktop files and file browser’s icon view across major versions.

However, as GNOME 3 no longer featured icons on desktop, a free-position canvas was no longer required. Various efforts were made to implement a less complex grid view, but the canvas refused to be dethroned easily.

On Jul 22, 2012, Jon McCann renamed the icon-view to canvas-view to pave way for a new icon view. I recall that around that time there was a nautilus git branch implementing a new icon view using GtkIconView. The branch has since been deleted, and I can’t find an archived discussion about it, so I can’t assert why it has been abandoned. I think it was partly due to poor performance for a large number of items.

In any case, GtkIconView, like EelCanvas, didn’t employ child widgets for the content items. This kept the content items from taking advantage of newer toolkit features. This was seen as a critical deficiency in the 2013 DX hackfest, which has prompted the introduction of GtkFlowBox, based on the earlier EggWrapBox widget.

Fast forward to 2016, Carlos Soriano starts working on a new GtkFlowBox-based view. It was discussed in a hackfest later that year, but it was concluded that the performance for large directories was the biggest problem. It has been included in releases as an experimental setting, but couldn’t replace the old canvas.

Another reason why the canvas stuck was that it was a requirement for the icons on desktop. While GNOME 3 didn’t use this, it was still a feature that was supported in nautilus and enabled in some distributions.

Carlos has initially tried to separate the desktop icons into a separate program, but in the end the only viable solution was to drop the desktop icons implementation from nautilus.

Enter GTK 4

In the early days of GTK 4 development, Ernestas Kulik has ported Files to that new in-development GTK version. This notably included a GTK 4 port of EelCanvas. It looked like the canvas would survive yet another major transition.

However, GTK 4 would take a few more years to be developed, and the growing API changes would end up making a port of EelCanvas all but viable.

The limited performance scalability of GtkFlowBox when used as a grid view for content apps has lead GTK developers to create scalable view widgets, which ultimately resulted in GtkGridView and its siblings, available in GTK 4.

Now, this left Files development in a sort of a chicken and egg problem: adopting GtkGridView required porting to GTK 4 first, but porting to GTK 4 required replacing EelCanvas with something first.

Interregnum

So, I’ve picked up Carlos experimental GtkFlowBox-based view and completed it, in order to use it as a stand-in for GtkGridView until after the app is ported to GTK 4.

It has reached feature parity with the canvas view, which is finally going to retirement.

Old and new grid views side by side — Old (EelCanvas-based) grid view on the left. New (GtkFlowBox-based) grid view on the right.

I’m deleting EelCanvas in the git repository of nautilus, but the legacy of GnomeCanvas lives on in other software packages, such as Evolution or nautilus forks nemo and caja.

Merge Request showing the diff. — One does not simply remove 20k LOC. ?

When is everyone’s favorite cephalopod file browser getting ported to GTK 4?

Back a few years

Let’s start with some history. GTK 4 has been in development since 2016 and it’s been expected that the Files application would be ported, obviously.

In 2018, a Google Summer of Code project from Ernestas Kulik produced a port of Files to GTK 3.9x, the development version of what would become GTK 4. It included a port of the custom EelCanvas widget (used to implement the Files icon view).

Although it was not meant for general use, Ernestas’s port was very useful, both for the development of GTK 4 itself, as well as the preparation of the Files app for the future. Many compatible changes were applied to the master branch, which both improved the code design and laid the preparations for a later port to GTK 4.

Since then, GTK 4 has grown a framework of scalable list model views which are expected to revolutionize what content-browsing apps like Files can do.

Fast forward to today

GTK 4 has been stable for a year now and other GTK 4-ready dependencies are available now (libgnome-desktop-4 and libadwaita).

However, GTK 4 has changed a lot since 2018, so much that a rebase of the early port branch was no longer viable. Instead, I’ve been cherry-picking as much as possible from Ernestas’s branch and prepared a new roadmap with help from our community.

When is it happening?

The always safe reply is: when it’s ready.

The main development branch is already dedicated to this porting effort, and I’m focusing my personal contributions on that.

My desire is for the switch to happen before the GNOME 42.alpha release. If we miss that target, don’t expect a new version before GNOME 43.

How to help?

If you, like me, wish to see GTK 4 Files ready for GNOME 42, let’s join efforts!

Currently, the low-hanging fruits are from this ticket to stop using gtk_dialog_run(). In most cases it should be easy to replace with the “response” signal. Just pick a task from there!

I’d also like to get some help from developers who already have experience porting applications to GTK 4, namely with peer-reviewing the merge requests I’ve been pushing.

Nothing to show yet?

No. There isn’t a GTK 4 build yet.

However, some enhancements are already being prepared with GTK 4 in mind, such as a new scrollable pathbar and the thumbnail shadows.

Here is how they look like under GTK 3:

Month: December 2021

The icon view is dead, long live the icon view!