I think this is a serious regression from Jessie. In Jessie it was, as is the expected behaviour, possible to sort the search results by name, size, modification date etc. Currently the results have a random order and therefore are close to useless. Please fix!

Please fix it here too!

*** Bug 782014 has been marked as a duplicate of this bug. ***

(In reply to Elias from comment #2)
> Please fix it here too!

You can register your interest simply by adding yourself as a CC. Additionally posting "me too" style comments that don't add any usable information is not helpful (and I say this as someone who has made such comments in the past!)

Anyway, your "here too" presumably refers to how you were referred here from a duplicate bug, so there is only one thing to fix, no "too" about it. :P

The last comment on this issue was two months ago. This is why I was trying to attract some attention to it as I come across it often, and it hasn't been addressed yet.

I did not know I could have done that by adding myself to the CC list. I wonder if it is on this basis that the developers are notified about an issue.

Thank you.

Elias,

Problem with commnents is that it notifies *everyone* adding more email. If you want to bring attention I suggest to ask on IRC or mailing lists.
But it's true this is hard, lot of tasks to do so priorities switch around...

The issue is still there in the current version and it has been reported on launchpad as well
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1698351

To be clear, this is by design, I think there was a bug with a longer discussion about it.

There's this for the search, plus another bug linked therein for the recent view.

*** This bug has been marked as a duplicate of bug 751649 ***

I note the "by design" comment - thanks for clarifying - and would like to add my view:

I have stopped using Nautilus due to this change (removing sort from search).

My classic use case:
1. Search for  item of interest.
2. Click date modified column to show most recently modified files first.

I use this a lot, most of the time in fact, and I could not survive without it.

Please consider restoring this regression.

I am also suffering from this regression.

Manual sorting was removed on purpose (see https://bugzilla.gnome.org/show_bug.cgi?id=751336) with the following explanation:
"Following what we did in the canvas view, and what the file
chooser is doing, we disallow the manual sorting on recent
and search for list view as well, since it kinda defeats the
point to allow a diferent sorting in those situations."

Apparently, Gnome devs confused searching with sorting, which are actually two different things. It's really scary how lightheartedly they deprecate things for design purposes without any attention to usability. It makes me wonder whether Gnome devs ever use Gnome in real life.

(In reply to andreas.tsourouflis from comment #11)
> Apparently, Gnome devs confused searching with sorting, which are actually
> two different things. It's really scary how lightheartedly they deprecate
> things for design purposes without any attention to usability.

I'd like to point out one article of the Code of Conduct: "Assume people mean well". In this case: don't take the fact that other people's opinions differing from yours means that they (A) don't know what they're doing or (B) don't care about/did not consider usability.

You can approach this positively as others have: by emphasising things in a way that maybe hasn't been considered yet.

For that reason, of trying to have a productive discussion, I'll reopen this in case it can be reconsidered, rather than leaving it closed as a dupe.

But just complaining and assuming bad faith are not the way to have a productive discussion.


> It makes me wonder whether Gnome devs ever use Gnome in real life.

I guess this felt like a decisive rhetorical flourish at the time, but it's absurd. Of course the designers and developers use GNOME.

It's just that not everyone uses or interprets it in the same way. That's a good thing. You can provide an alternative perspective on it without portraying others as blindly sabotaging it from afar, or whatever this is meant to be.

(In reply to Daniel Boles from comment #12)
> (In reply to andreas.tsourouflis from comment #11)
> > Apparently, Gnome devs confused searching with sorting, which are actually
> > two different things. It's really scary how lightheartedly they deprecate
> > things for design purposes without any attention to usability.
> 
> I'd like to point out one article of the Code of Conduct: "Assume people
> mean well". In this case: don't take the fact that other people's opinions
> differing from yours means that they (A) don't know what they're doing or
> (B) don't care about/did not consider usability.
> 
> You can approach this positively as others have: by emphasising things in a
> way that maybe hasn't been considered yet.
> 
> For that reason, of trying to have a productive discussion, I'll reopen this
> in case it can be reconsidered, rather than leaving it closed as a dupe.
> 
> But just complaining and assuming bad faith are not the way to have a
> productive discussion.
> 
> 
> > It makes me wonder whether Gnome devs ever use Gnome in real life.
> 
> I guess this felt like a decisive rhetorical flourish at the time, but it's
> absurd. Of course the designers and developers use GNOME.
> 
> It's just that not everyone uses or interprets it in the same way. That's a
> good thing. You can provide an alternative perspective on it without
> portraying others as blindly sabotaging it from afar, or whatever this is
> meant to be.

I apologize for the tone of my comment. I didn't mean to insult anybody.

This issue affects me too. I'm looking for a nautilus alternative because of it.

I thought I might offer a couple of use cases where the removal of file sorting from search makes Nautilus less usable for me.

Use case 1 : I work with scientific data, and silly file names are one of my perpetual annoyances (this is a near-universal headache in many of the sciences). For example, there are a lot of programs that I use that accept a base name as an argument, and then generate hundreds and sometimes thousands of files that are all variations on [base name]_[some other stuff].[extension], often organized into complex and sometimes nonsensical folder hierarchies. Usually, I'm only interested in one or two of these files. Usually, it's the one that was created last, or the one that is the biggest.

It is VERY useful to be able to search for the base name (it's often the only memorable part of the file name), and then sort by date, size or both. That's how I find the right file one the command line. For this use-case, Nautilus forces the user to scroll through the directory conducting the search by eye. This is a pretty miserable task when you have thousands of files to look at.

Use case 2 : When working with large collections of photos and videos, often the names are automatically generated by the camera. That means they have very little searchable information in them. The user will probably not be able to refine the search to a small enough list from which it would be reasonable to make a selection by matching only information contained in the name. For that, other metadata is highly valuable, and the best way to use it is often to sort it.

Use case 3 : Both problems at once! Many scientific datasets are, at least in part, collections of images. Many professional and amateur artists (photographers, videographers, podcasters, musicians...) face the same basic problem -- lots and lots of files with generated names that have been processed to make even more files with even more generated names.

In Case 1 or Case 2, there is usually a perfectly good solution on the command line. But, when you have a gigantic pile of un-thoughtfully named files, some of which are images or video or audio, and some of which aren't, a graphical file browser can be really wonderful. Combine searching, sorting on metadata and the ability to display thumbnails, and suddenly a lot of pain just goes away.

Nautilus is not just a set of training wheels for novice users. It is a powerful file management tool that is complementary to command line file management. In my opinion, removing sorting from search makes it less powerful without making it more intuitive.

Probably not very many people will care either way, but the people who do care will care a lot. For others, the only cost is seeing "Size" and "Modified" in black instead of gray when they use the search feature in Nautilus. That doesn't seem so bad.

Hey Russell,

The cases you mention is why we have the filters in the search! Click the arrow down and select to show files only for a date like today (case 1) or filter by metadata (case 2).

(In reply to Carlos Soriano from comment #16)
> Hey Russell,
> 
> The cases you mention is why we have the filters in the search! Click the
> arrow down and select to show files only for a date like today (case 1) or
> filter by metadata (case 2).

I usually have no idea what the actual date range is or what the interval between files might be (sometimes it's less than a second). If I just want the last file created of a particular type, there doesn't seem to be a way to make a filter that does that.

Even if you could create a filter with that effect, the fact that the Date/Time column is isn't shown in the search results means that unless your search returns EXACTLY the file you are looking for, you can't know which one is the one you're looking for. They're displayed in an arbitrary order that the user cannot influence.

For example, the directory I'm looking in has about 13,000 files in it. There are about 22 different base names, each with about 600 files. For each base, about ten to twenty of them are the right file type (FASTA, as it happens). Each represents a checkpoint in process that converges in a variable number of steps. So, I happen to want the smallest one. However, there are always two FASTA files generated by another part of the process that are always tiny (one record each), and so I actually want the third smallest file.

A user might want to do something similar, but based on creation time rather than size.

This would be delightfully easy with sortable search results. Filters are a nice way to exclude file types I don't want, but they cannot replace column sorting. Filters are complimentary to sorting, but alone do not effectively address the use case where you have a large number of similarly named files that need to be sifted through by their metadata.

If a widget displays list of files, people have (reasonably) expected simple, robust support for sorting by name, type and date for thirty years. Try it out in System 6, released in 1988 :

   https://jamesfriend.com.au/pce-js/system6/

In System 7 (released 1991), you had the modern behavior, where the user can sort by a column heading by clicking on it. Try it out here :

   https://jamesfriend.com.au/pce-js/

Displaying files in a list without being able to just click a column heading to sort them is just... weird.

> Even if you could create a filter with that effect, the fact that the Date/Time column is isn't shown in the search results means that unless your search returns EXACTLY the file you are looking for, you can't know which one is the one you're looking for.

Oh yeah, we should allow to add columns to search (not sure about sorting though).

Almost one year later; is there any progress to solve that bug?

No.

I created a new issue on github https://gitlab.gnome.org/GNOME/nautilus/issues/888

It has been clear that this is not a bug. It was a feature that was intentionally disabled by Gnome devs because they thought that searching and sorting should not be combined. 
It has also been clear by now that they do not intend to restore it, because they are not convinced by the arguments brought up here.

Not complaining, but feedback for what it is worth. Changes (design or otherwise) such as this and several others in nautilus were the final straw in my move to MacOS for laptop/desktop.

Closing this one in favor of the one in GitLab https://gitlab.gnome.org/GNOME/nautilus/issues/374.

Keep in mind this is a technical issue tracker (both BZ and GitLab), comments that are not either some new use case or specific design comments that haven't been brought yet are not appropriate here.

Feel free to discuss them in forums or mailing lists, where a more informal discussion is welcome.