GNOME Bugzilla – Bug 587040
GTK+ and Nautilus have different ideas on sorting order
Last modified: 2021-06-18 15:33:11 UTC
Apparently the GTK+ file chooser and Nautilus have different ideas on how hidden files should be sorted. GTK+ file chooser displays hidden folders first, and regular folders second. Nautilus sorts regular folders first, hidden folders second. I'm finding myself where my files went for a couple of milliseconds at a time when navigating between the different views during the day. This is quite trivial, so I'm certain people have lots of ideas on The Right Way to Do It. :) I don't really care myself, as long as it's the same. Other information:
to rephrase that: I find myself _wondering_ where my files went for a couple of milliseconds at a time.
I've just tested dolphin (kde4): hidden files first It should be better to have the same behaviour accross different desktop environments, so new users won't get in panic :)
I've been discussing this on irc. We clearly need to make a decision and stick to it consistently. I think the choice ultimately rests on how people use hidden files. If they show them all the time, then having them sorted after the usual stuff seems like the right choice. If people just show hidden files for a specific task and then hide them afterwards, it might be best to have them first, however.
Nautilus is doing it right here. With nautilus behavior , - the regular files/folders dont have to move , the hidden files just show up below. [fewer files change position] - when we toggle the hide/unhide the view refreshes, so there isnt really a confusion over the files being appended below and not grabbing user attention If we change the behavior the user files and [xdg]folders move to the end and often out of browser view[one would have to scroll down] .. and I dont really see why the regular files/folders should move down and hidden files given more priority. (In reply to comment #3) > > If people just show hidden files for a specific task and then hide them > afterwards, it might be best to have them first, however. User would [most probably?] understand that selecting "Show Hidden files" will show extra/more files and expect files showing up below[in excess of] the existing files. We should however get the inconsistency fixed in gtk file chooser , to match Nautilus.
I seem to recall that this got fixed in GTK File Chooser. Am I right?
(In reply to comment #5) > I seem to recall that this got fixed in GTK File Chooser. Am I right? I dont think so.
Does anyone have a bug number for the GTK+ File Chooser bug?
(In reply to comment #7) > Does anyone have a bug number for the GTK+ File Chooser bug? Couldn't find one, so filed Bug 636526 .
And "ls" sorts them in natural order as if the "." was not there at all: .cache cc-bt.txt .config crash.txt I think this probably makes the most sense. If you explicitly turn on the hidden files you want to see them. If the "." is purely there to indicate that the directory shouldn't be shown by default then the name of the file is what follows the dot. And you will likely look for the file based on the name. It seems a bit weird to have two separate sections (far apart) for things that start with "c".
*** Bug 358812 has been marked as a duplicate of this bug. ***
I would just like to weigh in my agreement with Vish. Most human friendly method would seem to be the Nautilus format of Normal first, then Hidden. Like so: Normal folders, Hidden folders, Normal files, Hidden files
A screenshot of Nautilus vs GTK https://bug358812.bugzilla-attachments.gnome.org/attachment.cgi?id=211686
And this is STILL going on in the 3.20 versions. What do we need to do to get Nautilus and GtkFileChooser to agree on how to sort? I thought a unified GUI was the whole point of all this...
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.