Hi,
from the past Windows times, I was used to prepend files or folders with a hash sign “#” to make them appear first in the file explorer view.
In Nautilus, when I prepend a folder name with #, it gets listed last.
When I prepend a folder with any other symbol, the symbol seems to get ignored and the folder gets sorted by the first alphabetic character.
My two questions:
a) is there any symbol / sign I could use so Nautilus lists that file /folder first, ie before alphabetic characters?
b) or is there a configuration / extension which adjusts the sort order?
Also, could someone please point me to the spot in the source code where the sorting happens? Especially the special case that items with # gets listed last? I am no C guy, but I guess I’ll understand the code when I look at it.
Nautilus uses stdlib’s strcmp to sort files. Before that, it passes the file names through g_utf8_collate_key_for_filename function to sort them using system locale’s collation. However, # is explicitly moved to the end the list.
I would use 0 as a prefix if I wanted to move some file to the top, as numbers are usually sorted before letters in most locales. Though if you already start some file names with 0 you will need to come up with something better (e.g. multiple zeroes).
Huh… just realized that sort order is different depending whether you are looking at a folder directly or via a “save as” dialog - hm, this seems not intentionally.
just realized that sort order is different depending whether you are looking at a folder directly or via a “save as” dialog - hm, this seems not intentionally.
Well, it’s intentional in the sense that nautilus and the GtkFileChooser use none of the same code, so the extent to which they DO operate the same way is more luck than anything else.
GtkFileChooser uses a fairly standard GtkTreeSortable, and sets sort functions based on the display parameters and the sort column. Ultimately, the name sorting comes down to a function based on strcmp, just like Nautilus’, but without the special-casing of '.' and '#' leading characters that was added to Nautilus’ sorting.
Nautilus’ sorting is actually pretty flaky. All that hand-coded, special-cased logic can tend to break down in corner cases. I filed a bug years ago about its handling of filename extensions, where sorting gets completely bonkers.
Thank you! I really enjoy these detailed answers, especially the links to the source code.
I do not know anything about the architecture of Gnome and its applications, but from an external view it would sound reasonable to have some common libraries for common functionalities.
The main issue with having a common library is that different projects expect a different stability – GTK requires very stable APIs while applications like Nautilus want to be able to experiment freely. One possibility would be having Nautilus provide a GTK module overriding the default file chooser with its own but GTK is removing module support due to the very same concerns about stability. Alternately, Nautilus could provide file chooser portal for Flatpak which GTK will use but its features are limited compared to GtkFileChooser.
The main issue with having a common library is that different projects expect a different stability
From my user perspective Gnome feels like one project. Whenever there is a new release of Gnome, there are new versions of Nautilus and so on. Maybe that is not entirely true, and maybe that changed recently, as nowadays you can have newer versions more easily with flatpak or snap.
while applications like Nautilus want to be able to experiment freely
From a user perspective - I neither want my file explorer to be experimental, but much more to be stable and behave consistent.
That said - I am an open source maintainer/contributor myself, and I know there is only so and so much free time and being stable and consistent maybe isn’t the most fun thing in software development.
I am very, very happy that I am able to use Gnome and Linux.
Because when I think “Nautilus”, the first things that come to mind are descriptions like “cutting-edge”, “experimental”, and “feature-packed”.
If anything, I think what we’re seeing here are the scars of having a two-DECADE-old legacy codebase. Most of the Nautilus file-listing / sorting code likely predates the GtkTreeSortable API entirely. Which, you know, isn’t to knock it… it’s long in the tooth, but it’s a metric ton of code to have to replace if anyone wanted to modernize it. (Which is why it’s been hemorrhaging legacy features/code over the past few years.)
While GTK is a part of GNOME Platform, it also supports other platforms and thus a greater care and stability is required. See this topic discussing the relationship between the two.
GNOME platform design is still evolving. It is much easier and better for stability if the evolution is done in applications than in the low-level libraries. Especially with the different development cycles – GTK 3 is basically finished from a design point of view. Unfortunately, the consistency will suffer in the short term.
