As the title, this is a spin-off of my last post in which I’ll talk about on Files list view instead of grid view.

But before that, a brief summary of what happened in-between.

Legitimate succession

In my last post we were at the interregnum: Files grid view was temporarily managed by GtkFlowBox. Since then the switch to GTK4 has happened and with it came GtkColumnView to claim its due place.

Despite that, GNOME 42 couldn’t ship the GTK4-based Files app (but it still benefited from it, with the new pathbar and more). Can you guess whose blame it was?

A view of trees

That’s how the spin-off starts.

Files list view has for a long time been managed by GtkTreeView, a venerable GTK widget which is still in GTK4 and didn’t have major API changes.

What looked like good news, for ease of porting, was hiding bad news: its drag-and-drop API is still a nightmare.

Drag and drag

GTK4 bring a new drag-and-drop paradigm to the table that makes it dramatically easier to implement drag-and-drop within and between apps. But GtkTreeView doesn’t employ widgets for its rows, so it can’t use the new paradigm.

So, it does its own thing, but with a different API from GTK3 too. I tried to use it to restore drag-and-drop on list view, but:

1. it was laborious and time-consuming;
2. grid view, which still lacked drag-and-drop support, couldn’t benefit from this work;
3. it might require debugging and improving GtkTreeView itself.

So I realized GtkTreeView was just dragging me down and we’d better move on.

 

 Because treeview

Users, designers, and developers have long requested things for Files list view that are basically impossible to do correctly and maintainably with GtkTreeView:

• rubberband selection;
• background space around items (for folder context menu);
• sort menu shared with the grid view;
• CSS styling;
• animations;
• rich search results list (without a clunky “Location” column);
• and more…

Much like EelCanvas, GtkTreeView doesn’t employ child widgets for the content items, which makes it lack many useful GTK features.

A view of columns

In my previous blog post I’ve mentioned how GTK4 brings new scalable view widgets. But I didn’t mention they are super amazing, did I?

The hero of this blog post is  GtkColumnView. It is a relative of GtkGridView, but displays items in a list with column instead.

Both take a model and use a factory to produce item widgets on-demand.

This has made it simpler to implement the new list view. All I had to do was copy the grid view code and make a few changes. That was going to be easy!

Famous last words

While the initial implementation was indeed a quick job, it was possible only by taking many shortcuts. Also known as very ugly hacks. It was good enough to share this screenshot in early February, but not good enough to release in GNOME 42.

As the 42 release was no longer the target, there was enough time to do things right. I’ve learnt more about GtkColumnView, fixed some GTK bugs, reported a few others and engaged with GTK developers on API discussion. Thanks their invaluable help, I was able to get rid of the hacks one by one and the quality and design of the code have improved significantly.

Old VS New

Who needs words when I have screenshots?

 

Columns & trees?

For a long time, Files has got an optional feature for list view which allows expanding folders in the same view. I don’t use it, but still did my best to implement it in GtkColumnView.

However, this implementation is still very unstable, so there is a chance GNOME 43 won’t have this feature. If you can code and want this feature to be included in GNOME 43, you can pick up on where I’ve left, your help is welcome!

A view of cells

Unlike the previous blog post, I’m going to share a little about the code design.

As mentioned, both GtkGridView and GtkColumnView use a model. The new Files list and grid views use a NautilusViewModel (containing NautilusViewItem objects) and share a lot of model-related code under a NautilusListBase abstract class.

src/nautilus-list-base.c: 1291 lines of code
src/nautilus-list-view.c: 1139 lines of code
src/nautilus-grid-base.c: 502 lines of code

In order to maximize the shared code, the child widgets of both views inherit from a NautilusViewCell widget class:

• in grid view, each item creates one cell widget: NautilusGridCell;
• in list view, each item creates one cell widget per column:
  • NautilusNameCell for the first column.
  • NautilusStarCell for the last column.
  • NautilusLabelCell for every other column.

Thanks to this cell abstraction, NautilusListBase can also hold common code for child widgets of both views, including event controllers! And this means they are also going to share drag-and-drop code!

Reviews welcome in https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/847