My second (full) GUADEC

Back to GUADEC

Four years after my first attendance of GUADEC, in Thessaloniki, I was fortunate enough to once again attend, in-person, the main GNOME conference, which was hosted this year in the enchanting city of Riga.

These were four long years! Alright, I’ve watched the online editions of 2020 and 2021, but that doesn’t count. Honorary mention to the Berlin “mini-GUADEC” in 2022, which was de facto a satellite venue and which I was very glad to attend in-person. It did have some of the GUADEC spirit and that was where I first met a lot of faces who I was very happy to see again this year.

Travelling from the diametrically opposite corner of Europe, and constrained by the number of PTO days I could to allocate, I couldn’t avoid air travel, but I’ve at least managed to replace one airplane connection with a high speed train travel.

Me in forground, House of the Black Heads in the background, in Riga

My First Talk

While contributing to nautilus, I often find myself doing code archaeology, i.e., looking into past revisions to make better decisions and avoid past mistakes. But there is also the fun of looking at how different things were 20 years ago. Last year, when I blogged about some of these findings, I was surprised by the  public feedback, both nostalgia from people who remembered that, and surprise from people who had never seen it.

That was when I realized it could be a good idea to share more such content as a presentation for GUADEC 2022. I even drafted the talk proposal, but in the end didn’t submit it because I was busy with life, the GTK 4 port, and 2 GSOC interns. So, this year I decided to go ahead and I was very happy to be accepted as a speaker for GUADEC 2023!

The original intention was to have other nautilus contributors join me to speak about on-going developments and future plans, while I focused on the history of nautilus only. But I was the only one who could make it to Riga, so I ended up taking up the stage alone to talk about past, present and future. I must admit I became a little nervous the 5 minutes before the talk!

But it went great. The room was full and I enjoyed seeing people react to both screenshots from the past and demos of new enhancements coming  in the room. The questions from the public after the presentation were very relevant and made for a great discussion. I was very happy to share how healthy and fun the project is right now.

Me giving a speak at GUADEC

The hallway (and canteen)

GUADEC is not just the public talks. It’s also having GNOME contributors bump into each other and get productive results from these collisions. I had very fruitful conversations during coffee and lunch breaks.

Once at lunch, I was sitting on the table with just the right people to clarify some questions regarding Files search: Carlos and Sam, from tracker team, and Allan, from the design team.

I even got dragged into a guerrilla usability testing by the design team, for the new workspace indicator.

 

Social events

In the first day, I joined the Latvia Old City Center guided tour, which I loved, despite the rain at the end! I was very lucky it was rescheduled from the last day, when I wouldn’t be able to join.

Besides the official social events, as usual in GUADEC, it’s easy to organize and join informal activities. I had great conversations in bars while metting or getting closer to more fellow contributors. Building these bounds and trust makes collaboration so much easier and enjoyable!

I almost skipped the beach evening. But fortunately changed my mind just in time to catch the train to Jürmala with a amazing group.

Sand sculpture in the beach in Jürmala

 

Final words

I cannot finish without praising the local organizing team, for the venue was great and everything went smoothly for me as a speaker and attendee. I’m also very thankful to the GNOME Foundation for sponsoring my travel and lodging. Last but not least, I send cheers to Pedro Sader Azevedo, who was my roommate at the hotel, and a very talented new contributor! I hope to join everyone again in a future GUADEC!

 

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