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.

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.

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.

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

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

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. ?

Files and GTK 4

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:

Files 40.beta: More productivity and some eye candy

Development of the nautilus project has picked up the pace for version 40, thanks to contributions from multiple people, new and old contributors alike.

I’ve previously blogged about the new Creation date property and the enhanced Wallpaper action, and this time I’m talking about changes which have made it into the beta or are set for the final release. There is a mix of enhancements, bug fixes and redesigns. And lot of screenshots.

Tab-completing path typing

The Files app has got a keyboard-only interface which allows navigating into a folder by typing a path. You can just start typing a path beginning with /or ~ to enter this mode, or Ctrl L if you want a relative path from the current location.

James Westman has enhanced this feature with automatic path completion suggestions. Read James’s blog to see it in action. It’s much more useful and enjoyable now.

File conflict automatic renaming

I’ve implemented an usability improvement which has been suggested by Jon McCann: if you move or copy a file but don’t want to overwrite another file with the same name, a new available name is automatically generated:

File conflict dialog suggesting a new name to avoid overwriting existing file — The automatically appended text is selected for convenience. You may want to replace it with something more meaningful.

Transfers & operations progress estimations

Making estimations on file operations is hard! Many factors may affect the speed, and unexpected file conflicts may change the final number of handled files compared to the initial count.

Over the years we have received reports of some weird results: unrealistic time estimations, incomplete progress bars for finished operations, number of files moved exceeding the total, etc.

Thanks to valiant efforts from Sachin Daluja and Ondrej Holy, the most visible and jarring bugs have been fixed, and the structure of the code has been improved.

Extracting password-protected files

After bringing us the new Wallpaper portal integration, Felipe Borges has extended our simple extraction process to handle password-encrypted archives correctly. Instead of failing without any explanation, Files now asks the password as it should:

Dialog with password prompt for zip file

Running scripts directly

The Files app has always featured the option to run executable text files (commonly “scripts”). However, it’s been hidden in a Preferences section requiring people to make an awkward compromise between opening (e.g. in a text editor) or running.

A couple of years ago I’ve ignited a community brainstorm about running executable files from the Files app. Revisiting the very useful feedback and discussion from that time, I’ve implemented a simpler, safer and more empowering solution: a new action to the context menu.

Context menu displaying "Run as a Program"

This new action comes with a bonus: it runs scripts in a Terminal window, which ensures the user gets feedback from and control over the script’s execution.

With both Open and Run available in the context menu for executable text files, the old preferences option became obsolete, which, along with a few other optimizations, has prepared the ground for the…

… redesigned Preferences!

Starting from Sam Hewitt’s design, this was further polished by Tobias Bernard and implemented by Adrien Plazas.

In addition to looking modern, the new Preferences dialog organizes the options in a more straightforward fashion, and describes them in clearer and more helpful ways.

Smooth visuals

You may have noticed the Preferences window has rounded corners all around. This feature has been extended to the main window, and Preferences too, by Christopher Davis.

Files app and Properties window displaying round corners

Testing

For testing the latest developments in GNOME Files, without modifying the Files app in your system, there is a Nightly flatpak. To install it, copy and run the following command in a Terminal:

flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref

The Nightly can now be launched from Activities, or with this command:

flatpak run org.gnome.NautilusDevel

(If your operating system doesn’t support flatpak out of the box, see the Quick Setup guide.)

Files 40.alpha: Creation timestamp & Wallpaper portal

Hi there, GNOME Planet.

In my last post I’ve promised that the next one would have screenshots of new developments in the Files app, and it’s finally here!

It took me longer than I expected back then. After the 3.38 release, I had to focus my time elsewhere: assisting and training local primary health care teams in managing and following up of the raising number of COVID-19 cases assigned to them. With this mission accomplished, in December I’ve picked up again on my GNOME contributions and have something to show you now.

Files 40.alpha

Last week we have reached the alpha milestone for the upcoming version 40 of GNOME Files. The highlights of this pre-release milestone are a long requested feature to show files creation timestamps and an enhancement to the Set as Wallpaper action.

Creation date

Finally the screenshots!

This was made possible thanks to Thunar developer Andre Miranda’s laudable initiative to implement the low-level glue for all GIO-based apps to benefit from. It was then easy for me to add the column to list view, and for Apoorv Sachan to add it to the Properties dialog (a nice follow-up to his GSOC project cleaning up the Properties code and UI).

This is a new feature, so it would be great to have people testing it before the final release. It’s easy to test, see instructions at the end of this post.

There as some open questions:

What to do for files and folders in file systems for which we don’t have access to the creation date (e.g. FAT, NTFS)?
Should we do something in case the Modified date is older than Created date, which is counter-intuitive even if technically correct?

Wallpaper Portal

There is a “Set as Wallpaper” action in the context menu for image files, which had a few odd behaviors which were not in sync with the user experience provided by the Settings app.

Thanks to Felipe Borges, not only have these problems been fixed, but the feature has been enhanced! Now you get a preview of the wallpaper, so you can confirm this was the correct picture and whether it’s going to look good, before confirming the desktop wallpaper change.

This is provided by the wallpaper portal created for sandboxed apps, but it works even outside Flatpak.

More coming soon

There are some more enhancements which didn’t make it into this milestone, but which I hope to be able to deliver before the beta milestone. I’ll talk about them in a future post.

I’m also very happy to see many new contributors fixing both major and minor bugs and implementing exciting features in the Files app. Now, back to reviewing the MRs, so that I can highlight their contributions in a future post!

Testing

For testing the latest developments in GNOME Files, without modifying the Files app in your system, there is a Nightly flatpak. To install it, copy and run the following command in a Terminal:

flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref

The Nightly can now be launched from Activities, or with this command:

flatpak run org.gnome.NautilusDevel

(If your operating system doesn’t support flatpak out of the box, see the Quick Setup guide.)

6 months later: nautilus co-maintainership and GSoC mentorship

It’s been a little over six months since my last blog post. It’s not like nothing happened since; I’ve just not got used to this yet.

As Ondřej Holý has previously blogged, the (now old) news are that he has invited me to be co-maintainer of the Files app. I was hesitant at first. I’m not sure if it was what’s called imposter syndrome, but I did worry I was not qualified to be maintainer, as I have no formal education on software engineering. I’ve started to overcome my doubts while attending GUADEC 2019, thanks to everyone who encouraged me, and I’ve finally cleared them thanks to Ondřej’s invitation and support. Now I’m happy to have accepted the challenge.

Later another challenge arose: becoming a mentor for a Google Summer of Code project. The first few times I was asked if I would be a mentor, I’ve dismissed it as not having time, but the actual reason was I believed I would not come up with a good project idea. As it turned out, I actually had already written a project idea, I had just not realized it until Felipe Borges told me it was a valid idea. And this past week the project has been accepted. Today I’ve had a great conversation with my student, Apoorv Sachan, as our first scheduled IRC meeting. Now I’m also happy to have accepted this challenge too.

Now, enough with boring personal experiences, right? Okay, okay, I hear you, I promise next post will have screenshots of new developments in the Files app!

My first GUADEC

My first…

This summer I’ve had my first travel by plane, which has been my first trip to Greece, where I’ve had my first in-person meeting with fellow GNOME contributors, by attending my first GUADEC. These were but some of my “first”-type achievements which made me very glad to have attended it, and happy to report on my experience.

…GUADEC

The conference was very well organized, it had an excellent, enriching track of talks and workshops, and two inspiring keynotes. There was a good balance of topics from both the technical side and the human side of GNOME. This is suitable for attracting more people who, like me, are not (primarily) programmers. Indeed, there was always something interesting for me in at least one of the rooms. Congratulations and thanks to the organizers and everyone involved in making this conference.

Setting a Positive Voice for GNOME by Britt Yazel and About Maintainers and Contributors by Georges Stavracas were two non-technical talks of high importance and surprising connections to each other. GNOME contributors are not always prepared to the exposure to and interaction with the Internet populace outside. If not well managed, this gives rise to bad experiences which alienate both users and contributors. We need more talks like this to understand the problems and develop better communication strategies, promoting the well-being of our contributors and the public image of our community.

I’ve particularly anticipated the first keynote, GNU HEALTH: The Fight for our Rights in the Public Health System by Luis Falcón, because the subject is very dear to me, a big problem I’m facing every day at work. Dr. Falcón has put a lot of thought into the problem and is creating a solution, so I was very glad to listen to his talk and to talk with him and other people about this topic afterwards. I’ve decided to learn more about GNU HEALTH and how I can help change my country’s NHS software policy.

Renata Gegaj and Clarissa Borges gave talks on user research and usability testing, which built a lot of momentum to apply these practices more regularly into our design and development process. Later, in the BoF days, Renata was also kind enough to apply some of her expertise to review some usability issues in the Files app. And since the conference Clarissa has been building a usability testing team.

These were some personal highlights, but I’ve also attended or watched the recording of other great talks. I’ve participated in the Unconscious Bias workshop, which, in a playful manner, demonstrated how varied life experiences are, and how that may limit our perception in many cases; while I was already aware of some of my biases, I’ve become aware of a couple of new ones. In the BoF days I’ve helped with the Newcomers Workshop and participated in the Inclusion & Diversity one.

Besides attending talks and BoFs, I have also been involved as a volunteer. Unfortunately, on the first day I arrived too late for the volunteers’ meeting. Despite that, I was warmly welcomed by the organizers and other volunteers, and I was able to help with gathering the lunch tickets and assisting speakers in talks. It was my first time volunteering in a conference, so I’ve learnt a lot.

At the venue I also was able to meet fellow nautilus team members and other people I used to talk with online, watch Carlos Soriano and Cosimo Cecchi doing a live MR review for nautilus (even getting one of my own MR reviewed), and try a demo of GNOME in VR (courtesy of Lubosz Sarnecki). At first I didn’t know anyone, but soon Felipe Borges found me and introduced me to other people. The Bingo was a great way for new faces like me to approach and start a conversation with new people (I even won a souvenir!). The whole community was very welcoming to me, and people I admired were really down-to-earth human beings (which actually made me admire them more).

During my stay in Thessaloniki I got to eat delicious food (as expected of Greece!), taste greek wine and ouzo, do outdoor exercises, have a picnic in the mountain, see the sunset on a pirate boat, visit the Rotunda museum, and share special memories with great people.

For all of above, I’m thankful to the GNOME Foundation for sponsoring my attendance.

Good Morning World

This is a deviation from the default “Hello World” title, not the name of a breakfast TV show.

Hi. I’m António Fernandes and this is my newly-created GNOME blog.

This is a belated debut, as I’ve been a foundation member for two years already. I’m doing it now thanks to GUADEC (the topic of the next post) and Sam’s challenge (which inspired the name for this blog).

My long story short: Thanks to Ubuntu Lucid, I’ve started using GNOME. Thanks to JHBuild, I’ve started using gnome-shell 2.9x. Thanks to the Bug Squad, I found an easy way to contribute back. Thanks to nautilus being top 5 in number of bug reports, I found a niche to seasonally triage the following years. With Carlos, I became part of nautilus team. And with Builder, I’ve learnt C and started hacking on nautilus.

Nowadays I manage nautilus issue reports and merge requests in GNOME’s GitLab, but I’m also very interested in UX design and usability. These are topics you can expect me to write about in this blog.