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.
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.
While I do understand the theoretical advantages of GTK4, a lot of these changes seem unnecessary, and a poor excuse to break backwards compatibility. The fact that such a massive component had to be reworked really shows the significance of the changes, and for what gain? The main reason to port seems to be to fit in with Adwaita’s new style, which doesn’t exist for GTK3 currently.
I also think the old custom canvas view has some advantages: it can evolve to suit Nautilus’s needs much more, tailored to selecting files. Various news outlets are complaining that much of GTK4 is private, in-particular the new list widgets, so apps cannot improve them, and relieving on general-purpose widgets for something as important as an icon view can lead to roadblocks down the road.
As someone who has tried multiple times over the years to create downstream patches for icon view in GTK’s file chooser, these new list widgets really seem to be making that much more viable in the new future.
All this wasted effort porting to GTK4 could have been much better spent on improving GTK3, which has just now started receiving recognition to be used in non-GNOME apps, especially as GTK seems to have been completely forgotten in “what GUI toolkit should I use for making an app?” threads.
Multiple people who have worked on and even maintained nautilus, as well as other content apps with a grid view, have concluded that the old canvas could not easily evolve to suit the project needs anymore. This is documented in the multiple pages linked through the post, which have been publicly available for years.
While porting this component, my priority has been to preserve feature parity and match behavior, avoiding regressions. The new enhancements and bugfixes that this change is going to unlock may only come after that first priority is soundly assured. I don’t expect them in the first release.
It’s very sweet of you to say my effort is wasted. It motivates me to follow your lead on improving GTK 3.
The majority of users appreciate all the effort people like you put into FOSS projects, specially the ones heavily used such as Nautilus.
Sincere thanks!
I fully agree! I really appreciate the courage to break APIs and existing structures to get into the future. Why shouldn’t we try new paths and use our new common knowledge to improve.
I kinda feel that driven by the past 2 years in Gnome i would like to contribute too and i feel very motivated by blog posts like that one 🙂
?
What a wonderful feedback – ‘wasting time on the new version of GTK but keep plodding along with an old version’ – A nonsensical position as far as I can tell. Forward progress always breaks some things in the short term while providing new avenues to follow.
The developers did spend time improving gtk3. They named that effort gtk4.
Back to the post, I didnt realise how gargantuan this task was and wouldnt have known without all the links to past discussions and attempts at improvements.
congrats on completing it!
Thanks for your great work Antonio (and the trip down memory lane! ♥). This thread immediately reminds me of a Twitter thread just days old now. If possible, try to ignore the negativity, your backed by many people excited for your work on Nautilus! It’s anything but wasted!
GTK4 is still agnostic and extensible. I recommend actually using it before spreading FUD.
I honestly can’t tell whether you’re being serious or not. The new list widgets in GTK 4 are like a million times more performant and, a million times more versatile, and a million times easier to work with compared to GTK 3. (This isn’t an exaggeration, by the way. You really can have millions of list items in GTK 4, using widgets, not cell renderers.) It’s not at all “theoretical” or cosmetic like what you seem to be implying here.
In fact, if you ask me, “What’s the number one thing you think should be improved in GTK 3?” I would say, “Make the list widgets more scalable and easier to use, like how GTK 4 does it.” Apparently many people thought the same, which is why GTK 4 is the way it is now, and I’m very grateful for it, because I, like most people, cannot afford to write or use custom widgets for something as common as list, tree, and icon views. It’s simply too much effort that would be better used to actually develop the app instead. That’s the whole point of using a toolkit.
Thanks for the history and the work to make this happen. Backwards compatibility takes a lot more work than most people think and a good many times it is impossible. For the people who have a requirement of the desktop being exactly like it was in 1998, 2008, or even 2018.. the code is still there and can be run. You might not get a bunch of new things, but in the end you may find that those new things are just going to peeve you off anyway. [I find myself continually in that state and end up going to the simplest view that is most NeXT1996 like.] That said, I don’t get to tell people what they can or can not work on unless I am paying them. Otherwise I am just making my debt to them even larger in criticism.
Thanks for speaking up! Testimony of reasonable people is really important.
One size does not fit all. I’ve mentioned nemo and caja because I’m glad these projects exist and keep pushing our shared history in a different direction.
Excuse this probably ignorant question, but… does that mean we can finally get file previews in the GTK file picker dialog? It’s been years since the initial git issue that suggested adding them, and also I’ve seen someone (probably one of the GNOME devs) say that the previews were rendered by the program that spawned the dialog and the switch to GTK4 means it will be now possible to implement previews in the file picker globally. Is that the case?
This is not related to the GTK file picker at all and I’m not a GTK developer.
There’s nobody who doesn’t want thumbnails on the file picker. If it hasn’t been resolved it’s because it is actually a very very difficult thing to get right. Don’t be fooled by the meme-spreading trolls.
Wow, removing 20 000 lines of code is very impressive! That’s almost 16% of the code lines in all of Nautilus according to cloc (excluding PO files).
Right! I felt it warranted tracing the origins of these LOC and that’s how this post happened!
This was amazing! thanks for this memory lane, i have been following gnome since that very beginning and all those names and library bought me joy to hear!
I’ve been a GNOME user since about 2000, and this is one of those things that comes up every few years, everybody points at, but nobody can get a good enough grasp to fix. I’m glad to see this progress, and looking forward to GTK4-based Nautilus.
What you’ve done here is a miracle. That code was *complicated*. Kudos for this work, it’s awe inspiring! (Anyone that says “why not fix the GTK3 version instead” is just not experienced with GTK3, nor GTK4, nor Nautilus.)
These words, coming from feaneron, the miracle-worker, mean a lot! Thanks ☺️
WOW! It really happend! Awesome! Thanks, keep up rocking.
Thanks, Lapo!
I like the job done!
Thank you for your work.
Nautilus is a core app of Gnome and porting any single core app to GTK4 is very welcome.
I hope that the Nautilus icon view will have a happy life again! I was the main developer of the icon view while it was under development by the Eazel team. I am glad there is still interest in improving Nautilus after all these years.
This post was a tribute to your work too, so I’m very happy you are reading it and glad you enjoy it! Thanks for kindly leaving a comment, it was a happy surprise.
Thanks for all you work!
Amazing work, thank you!
Amazing work, thank you!
Congratulations on this amazing piece of engineering! You’ve joined a small but amazing cabal of Nautilus developers whose skills are mad and amazing ! 🙂
Kudos to you Antonio and all the earlier contributors to the GTK4 port! This is a gigantic piece of work over a decades old codebase, it is great to see the pieces coming along so nicely on such a flagship GNOME application.
Awesome work, congratulations! And thanks for the history, this is always interesting to put things into perspective.
Awesome work. Nice to see Nautilus is getting major updates again.
That’s amazing work! Congrats for making this possible!
Thank you Antonio for your contribution. I have been following the development on Nautilus for a long time. A couple of months back ebassi was kind enough to explain the huge amount of effort it requires. I never thought it you guys were actually working on it till I found out from the gtk4 port track sheet. I sincerely thank all the developers involved in making this happen after so many years!
This is wonderful to see finally happen as a result of your hard work. You did what we couldn’t! Thank you. Keep up the great work.