I disagree. Thunar displays hidden files first, pcmanfm does the same, Konqueror does the same, as does GtkFileChooser. Further more changing this would result in inconsistency.

If the user displays hidden files, it is fair to assume he wants to seem the, isn't it?

GtkFileChooser just does a string sort with locale-specific comparisons.  "." comes before letters, so ".foo" will always come before "foo".

In contrast, Nautilus uses a fancier sorting method.  See nautilus/libnautilus-private/nautilus-file.c:compare_by_display_name():

static int
compare_by_display_name (NautilusFile *file_1, NautilusFile *file_2)
{
	const char *name_1, *name_2;
	const char *key_1, *key_2;
	gboolean sort_last_1, sort_last_2;
	int compare;

	name_1 = nautilus_file_peek_display_name (file_1);
	name_2 = nautilus_file_peek_display_name (file_2);

	sort_last_1 = name_1[0] == SORT_LAST_CHAR1 || name_1[0] == SORT_LAST_CHAR2;
	sort_last_2 = name_2[0] == SORT_LAST_CHAR1 || name_2[0] == SORT_LAST_CHAR2;

        ...

If you look for SORT_LAST_CHAR1 and SORT_LAST_CHAR2, you'll find

/* Files that start with these characters sort after files that don't. */
#define SORT_LAST_CHAR1 '.'
#define SORT_LAST_CHAR2 '#'

This is *ancient* code.  The commit where this got introduced is a03bb1a31, going all the way back to November 2000.

Offhand, I don't see a good reason for Nautilus to do this.  Nautilus people, would you agree to taking out this code so that Nautilus sorts filenames as plainly as everything else - just with the collation key?

(In reply to comment #1)
> I disagree. Thunar displays hidden files first, pcmanfm does the same,
> Konqueror does the same, as does GtkFileChooser. 

Another browser doing it , doesnt mean they have got it right. (Not sure we need to consider about Konqueror though.)

> 
> If the user displays hidden files, it is fair to assume he wants to seem the,
> isn't it?

Yes, user would want to see them, but it does not have to move all of the user folders away. 
Consistency and familiarity are more important. There needs to be a smooth visual flow of information for the user. 

If we switch from a regular view to show hidden folders view, everytime it changes it looks like a totally different view, but it's the same location we are viewing. This is just because *everything* is re-arranged. 

Imagine a folder with 4 regular folders and 15hidden, if we want to pick something from a hidden folder to drop in the the regular folder, the regular folder is not in the same place. We now have to search for the regular folder's new location. The folder icons look the very same and it is not easy to differentiate hidden/regular either without reading the names.
(notice the same transition in Nautilus, the view is more familiar with just a few more folders)

If we leave the hidden folders to be displayed always, the user folders are never the first ones accessible.

GNOME HIG mentions in several places to keep common items in a consistent location, there is always a "Be consistent" mention. Increases familiarity and ease of use for the user.

(In reply to comment #3)
> If we switch from a regular view to show hidden folders view, everytime it
> changes it looks like a totally different view, but it's the same location we
> are viewing. This is just because *everything* is re-arranged. 

Did you actually test this on a recent GTK+?  The currently-selected file does not change position when you toggle "Show hidden files" off an on multiple times.  We actually preserve the vertical position of the selected file.

*Something* is going to move when you insert the hidden files somewhere.  If you sort them first, you'll have

  .hidden-folder1
  .hidden-folder2
  folder3
  folder4
  .hidden-file1
  .hidden-file2
  file-3
  file-4

And if you sort them at the end, you'll have

  folder1
  folder2
  .hidden-folder3
  .hidden-folder4
  file-1
  file-2
  .hidden-file3
  .hidden-file4

So if you are looking at the files, not the folders, *something* will move above them.  The best that the file chooser can do is to preserve the current selection's vertical position, which is exactly what we do right now.

(In reply to comment #4)
> (In reply to comment #3)
> > If we switch from a regular view to show hidden folders view, everytime it
> > changes it looks like a totally different view, but it's the same location we
> > are viewing. This is just because *everything* is re-arranged. 
> 
> Did you actually test this on a recent GTK+?  The currently-selected file does
> not change position when you toggle "Show hidden files" off an on multiple
> times.  We actually preserve the vertical position of the selected file.

In GTK+ 2.22.0-0ubuntu1(the latest in Ubuntu 10.10), it does not work like how you mention. Always the view is reset to the top, irrespective of whether the folder/file is selected or not.

> 
> *Something* is going to move when you insert the hidden files somewhere.  If
> you sort them first, you'll have

It's the difference between /something/ having to move and *everything* having to move.
We should always try to minimize what we can keep stationary.

As I mentioned earlier, if user has the hidden files always shown, then the Hidden files are unnecessarily given importance and are preceding the user files or folders.(that includes the half/backup copies of files or .tmp folders).

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

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new