The tree view is undead, long live the column view‽

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?

Old Recents list ─ misaligned thumbnails and name, wide Location column
New Recents list ─ Centered thumbnails, location as a caption, size column present
Old search results list ─ wide Location column, truncated full-text snippet, cannot change sort order.

 

New search results list ─ Sort menu, full snippets, location caption only for subfolder results
New List view ─ compact mode, rubberband selection, background space between and around rows

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

 

14 thoughts on “The tree view is undead, long live the column view‽”

  1. Amazing write-up, and thank you for all the insanely hard work you’ve been putting in. I’ve been watching the progress on Gitlab. Thanks!

  2. Switching Files on GTK 4 might give a chance to restore implementation of able adding files and folders on the desktop? As I know, from Files was removed desktop code, so with GTK 4 this feature maybe will be easier to bring back?

    1. The opposite, actually. Ever since the desktop icons module was taken out of Files, the code has been changed in ways that make it further incompatible with usage as implementation of icons on desktop.

      But that’s what’s making all these new features possible.

  3. Great article! Nice read!
    Many UX designers will be happy with the possibilities of the new design!

    Two small suggestions
    * Put the name of the file on top and the location at the bottom.
    People are looking for the name of the file first and then the location.

    * At some padding at the top of the row with the column names.
    This will make it just look more beautiful.

    1. Thanks for the suggestions. I don’t have a strong opinion on these two points, so indeed I welcome designers guidance.

  4. Please, PLEASE, while at it consider bringing back type-ahead, even as a non-default hidden feature buried somewhere in dconf. I’ve been keeping patching it back in since it’s been removed, but that surely won’t be possible anymore once this rolls out.

    1. That feature has been gone for a whole decade.

      Unfortunately, our search hasn’t been fast enough for a whole decade too.

      The good news: the code design of these new views is going to allow making search instantaneous for results in the current folder.

  5. Fantastic job, this was an immense amount of work. Whichever version this actually lands in, I’m sure users will notice.

    Thank you for all you do 🙂

  6. Good work!

    Side, very important note: One thing that needs to change in Files is merging bookmarks with places, or making places hideable. It’s easy to put a reset default bookmarks option in the settings or just in a right click menu for people who need them back. It’s really bad to have to look at a bunch of bookmarks I don’t use, and have to scroll past those, and scroll past removable storage, just to see my frequent bookmarks. Bookmarks should be the thing you have the quickest access to.

Leave a Reply

Your email address will not be published. Required fields are marked *