I like  this. The user get the control. Works good to me. I ll test it a little more. But good work!

Hopefully by now Ubuntu has enabled Tracker. If not, someone should really get that fixed. Search is going to suck without it and data on the effectiveness of the just-type search isn't very useful without it.

There are other bugs open for improving the performance of the search so we shouldn't get into that here.

As for "find". The pattern we are exploring for find is quite a bit better than the old type ahead find feature. But we need to be certain there is enough value in offering it in addition to the search - not just working around performance.

So, I don't think we want this in this form. I'm going to mark this as duplicate of the bug that we have open for evaluating a find feature.

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

Hello! Thanks for the work on this patch! I've not tested it till now, but I strongly support the proposal of re-adding this feature back to Nautilus.

Type-Ahead-Find is a well known feature and used in all common file-browsers, but is purpose is not to find or search a file. The purpose is to navigate quickly through the UI of the file-browser by typing known names of files and directories.

It is not in conflict with the the new search from 3.6, because this is for quick navigating. And this is the reason why the new search was critized so much, navigation was replaced by search. Therefore I suggest naming this feature:

Type-Ahead-Navigation

We are not working around the performance, this is something completely different. Just the naming is and was weird and let into an unnecessary conflict.

Benefits of "Type-Ahead-Navigation":
1. Navigating through known files by typing is nearly as fast, as using the shell
2. Searching, with and without a database, is always slower than navigating. Even with and fast SSD.
3. Searching offers a lot of possible results, while users navigate by expecting only a few possible matches in the current directory, based on their knowledge and relative position in the filesystem (which search can't have).A search querys a lot of directories and produces a lot of false positives, their is the attempt to mitigate this in list-view. The "navigation" will only present the local results of the current directory, which comes from the different semantic.

By the way, even the terms find and search are not "the same" in common language:
http://stackoverflow.com/questions/480811/semantic-difference-between-find-and-search

Peter has explained it perfectly.  I have tried to adjust to this new workflow for a while now, but it just doesn't work.  

In one of the projects I work on, there are many files and folders with the same name, so using the search for any of these is NEVER what I want to do.  However, I know exactly how this project is structured, and I'd like to be able to quickly navigate to the files I need.  Although the navbar is helpful in getting to said folder, once I'm there I have to scroll to find the relevant files.

To reiterate, I use type-ahead for navigating.  I actually rarely use search, if I need it I usually use command line because it gives me much better control of my search.  However, if I wanted to search for something I'd do so explicitly.

@William: I think you do not understand that tracker won't change anything to the type-ahead problem. But I guess it's useless to argue, you made your opinion and it won't change.

Thanks Ubuntu for fixing that on their nautilus 3.10 package, I don't have to backport nautilus 3.4 anymore \o/

> To reiterate, I use type-ahead for navigating.  

Me too, but I don't think this bug will ever be fixed, so I guess I will just use the Ubuntu patched version.

I want to add some perspective here about why we're not taking the patch upstream at this point, even as an option.

GNOME designs in general are moving away from solutions involving typeahead as it is today to address the issue of finding an item in a view. It is not - and likely won't be - in GtkListBox and GtkFlowBox for instance, which are the corner stones of future UI developments around views. Those widgets will have a different solution to address the use case. So if we were to add it back today, we would have to remove it in the long run.

Another way of looking at this is in fact that we already paid the price for removing this option; having it back just to remove it again in the long run is not going to help anyone, and Ubuntu is going to ship with this patch in any case.

We agree that some in-view find use cases are currently suboptimal in Nautilus, where search is not very effective for those, and we'll focus on developing a proper solution in git master instead of just putting it back to how it was before.

Hi Cosimo, firstly, thanks for engaging with us on this bug.

> 
> GNOME designs in general are moving away from solutions involving typeahead as
> it is today to address the issue of finding an item in a view. It is not - and
> likely won't be - in GtkListBox and GtkFlowBox for instance, which are the
> corner stones of future UI developments around views. Those widgets will have a
> different solution to address the use case. So if we were to add it back today,
> we would have to remove it in the long run.

I think I can parse this. Yet it is hard to interpret as anything other than 'you should not use type-ahead search'.

At the moment the justification seems to be 'because type-ahead isn't in GtkListBox or GtkFlowBox'. The justification for this is because there will be another (as yet undersigned solution).

Subsequently, can I now presume that any future designed solution for ListBox and FlowBox will differ significantly enough from how I (and I presume others) currently use type-ahead that a future removal will be noticeable UI churn.

This just leaves me more disappointed - because from my chain of reasoning above, it means that future type-ahead will not behave as current type-ahead used to, and thus 'you should not use type-ahead in its current form'. 

> 
> Another way of looking at this is in fact that we already paid the price for
> removing this option; having it back just to remove it again in the long run is
> not going to help anyone, and Ubuntu is going to ship with this patch in any
> case.
> 
> We agree that some in-view find use cases are currently suboptimal in Nautilus,
> where search is not very effective for those, and we'll focus on developing a
> proper solution in git master instead of just putting it back to how it was
> before.

Whether I will have to change my esoteric interaction model with directories containing hundreds of files remains to be seen.

Until that time however, this bug serves of another example of removing something that people used with neither replacement nor justification (until now) nor offering a comparable way to achieve the same task.

I want to raise some opinion on this. How about if we integrate type-ahead on the searchbar. One way is to add search mode beside the bar. 

Usually we get 
    [searchbar...               ][folder_name][All Files]
Then we can add [Top Level] mode also. 
Is it good enough?

If some user really want to use type-ahead all the time, then we can set it as the last choice and keep in this mode till changed.

I hope someday, we can see
    [searchbar...               ][folder_name][Top Level][All Files]
or somekind of it..

Notes: Sorry, I don't read carefully the discussion above. I write this in a hurry...

How such a regression should be possible ?

I upgraded my Debain stable to Jessie some days ago. I'll not speak here as a developer, as we can imagine that we've some specials needs; but I'll speak as a classical everydays user.

I installed many Debian Linux distros for classical end-users like my mother, friends parents, and many other people aroud me. I asked them about the "new Debian version", and everybody is quite exited to discover and try changes.

But today, I doubt. As a front end dev, I spend time watching people using GUIs. Very beginners always use mouse to find sub-directories in current directory. More advanced users (like my mother, 60 years old) use type-ahead fonctionnality. She stores and manipulate many photos, very well organized in sub directories. When she looks for a sub directory in a directory, she use type-ahead to quickly jump to the first letter. It seems that she don't use it for "2 letters"; just like a classical paper adresses book, she "goes to 'm' letter", than finish browsing with mouse.
When she doesn't remember where a file or a directory is, she use deep find feature. It's quite rare, as people using computers always browse same working dirs, we easilly remember paths.
I take my mother example here, but all users I know uses the file browser the same way (for whom who left the full-mouse state and are a little more advanced for using keyboard)
Deep search is not the default intended action for them. And neither it is for me, advanced user. When there is many files in subtree, like it is for my mother, my father also, and I suppose every user (of course for devs), default deep search is totaly useless, ressources consuming, and really longer. For something that is less that 10% of searches use, make it default is for me a non sense.

All that people won't be able to express themselves here. Because they don't speak English first (I'm not saying that bugs should be expressed in any language than english, it's certainly the most widely-spoke language), and even if they should, only devs and rare power users are aware of bugzilla.

For now, I'll install Nemo as file manager (thanks to a comment on a similar bug in Ubuntu project), and hope that we'll se some end-user logical changes coming out soon. 

Thanks for reading.

> > To reiterate, I use type-ahead for navigating.  

Me too; i'd like to point out that the old type ahead navigation still works on Gtk file selection dialogs... Sounds inconsistent to offer a different behaviour in nautilus IMO.

(In reply to Florent Thiery from comment #11)
> > > To reiterate, I use type-ahead for navigating.  
> 
> Me too; i'd like to point out that the old type ahead navigation still works
> on Gtk file selection dialogs... Sounds inconsistent to offer a different
> behaviour in nautilus IMO.

This is true and in fact my patch is based on that implementation.

(In reply to Florent Thiery from comment #11)
> > > To reiterate, I use type-ahead for navigating.  
> 
> Me too; i'd like to point out that the old type ahead navigation still works
> on Gtk file selection dialogs... Sounds inconsistent to offer a different
> behaviour in nautilus IMO.

Hi, yeah it was inconsistent. Luckily we implemented something similar to nautilus search in the GtkFileChooser now (even better for in my opinion), so everything it's coming to be more consistent for 3.18.

Hi,

Some time ago I noticed the change and searched the preferences to disable this misfeature. Didn't find the option.

Now I search again thinking there must be a solution since type-ahead boosts productivity and search is really annoying for everyday use. Here I am on this old bug-report.

What does it cost to restore this optionally with a setting? Like Ubuntu did but with a GUI so you just need to tick the checkbox.
Do nautilus devs use nautilus or another file browser?

I really don't get this change, now it's such a pain to browse my files I'm looking for alternatives to nautilus. Too bad I'm really a fan of gnome.

So frustrating.

We all know that the current approach, without a Type-Ahead-Navigation is a problem. Basically the assumption that a fuzzy search can replace a direct navigation was wrong, it is not about what is better, they are completely different approaches.
It would be the biggest improvment in the past years for GNOME, if we start working together instead on relying on a position that something is right or wrong. Let us use integrate, use and enjoy both features!

(In reply to Peter from comment #15)
> Let us use integrate, use and enjoy both features!

+1 why not a single dconf key to select the chosen behaviour ? Is there an architecture bottleneck that prevents that, or is this just because the initial feature developers are 100% certain that this is the only correct behaviour ?

Hi, see comment #7.
On the other hand we don't add options just because, we would have thousand of them if so =) and options means maintenance cost as you know... but we hope we can improve things with the new designs we have for 3.18 for the general searching.

(In reply to Carlos Soriano from comment #17)
> Hi, see comment #7.
> On the other hand we don't add options just because, we would have thousand

I really hope this wouldn't seen as 'just because'. If anything, the decision to remove it was 'just because' ('removing now because we hope to "fix" it years from now' doesn't sound like a valid reason to me).

> of them if so =) and options means maintenance cost as you know... but we
> hope we can improve things with the new designs we have for 3.18 for the
> general searching.

I hope so too :)

Seriously? No type-ahead? Intentionally? And without an option to enable it? WTF?

I have to say that Carlos Soriano is displaying an evident lack of interest towards what popular opinion is in this matter.

"In any case, what I'm interested to hear is about problems, goals and use cases.."

Well, here's a problem for you, Carlos: I'm in /etc folder on a remote machine and I start typing "ngin" and the system just halts for 8 seconds, before showing me some weird results. Do you think this is problem enough?

(In reply to katherineave from comment #20)
> Well, here's a problem for you, Carlos: I'm in /etc folder on a remote
> machine and I start typing "ngin" and the system just halts for 8 seconds,
> before showing me some weird results. Do you think this is problem enough?

Oh, that's bad.

Recursive search is supposed to be disabled on remote locations to prevent problems (and can be explicitly enabled). In which case, the search operates only on the list of files which are already loaded in the current view, which should be very fast. Maybe the location is not being correctly detected as remote?

Can you please file an issue about this bug? https://gitlab.gnome.org/GNOME/nautilus/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=

In the description of the bug, it would be useful to know if the returned results returned were from the same location or from child folders.

katherineave: I have to say that you will have to read and follow https://wiki.gnome.org/Foundation/CodeOfConduct if you'd like to continue participating in GNOME venues. Thanks.

katherineave:
Please consider that behind the other keyboard is a human. You likely don't have a contract with this person. This person as developer and maintainer has a own vision about the features of the application and restricted time.

Anyway. Things which should have happened, happened. The nightmare around GNOME 3.6, which removed a lot of beloved features. Since then Carlos really improved Nautilus! Carlos wasn't in charge during the removal.

I've your starting blaming it is unlikely that the developers care, because they are humans and can become grumpy like humans.

btw.
Any search in Nautilus rely on four engines:
– The current view cache (the fastest)
– Tracker (second fastest)
– Recent
– Simple (crawling the filesystem)

They run in parallel. So your slowdown should just be a, probably small, bug? And regarding my own comment from above, Nautilus is already doing the "fastest". That should as fast as listening the files of a directory.

Anyway. Things which should *not* have happened...

Peter:

try to perform a search on a remote machine (with not so good connection, to accentuate the issue), then when the results appear, hit Esc. What happens? Oh, it loads the view again, which takes another second or two. Just more consequences of the decision to force Search on users when they don't need it.

(In reply to katherineave from comment #25)
> Peter:
> 
> try to perform a search on a remote machine (with not so good connection, to
> accentuate the issue), then when the results appear, hit Esc. What happens?
> Oh, it loads the view again, which takes another second or two. Just more
> consequences of the decision to force Search on users when they don't need
> it.

You are free to send us a patch that avoids replacing the view entirely.

Andre:
I have no idea what you're trying to imply. But you're welcome.

Thanks Peter

katherineave: https://wiki.gnome.org/Foundation/CodeOfConduct asks you to be respectful and to assume that people mean well. Criticize ideas, not people.

Today, as often, I installed Ubuntu to a new Linux user, coming from Windows. Everything is great and well designed, intuitive, and quick ... then ... this lady began to feel comfortable and wanted to quickly jump to the photo named "IMG232.jpg"; so she started to type "IMG" on her folder, containing hundred of photos and sub-folder and ... yeah, I suddently remembered WHY I gave up using Nautilus a bunch of years ago. 
How to explain this to this lady ? After a while she understood that those files that disappeared and appeared under her eyes wasn't a deletion, but a search result. How to know WITCH IMG232.jpg was the one of the **current** folder ? The folder of the bro's weeding ?
She logically asked me how to change this default strange behavior and I logically said to her "oh yeah, I remember this is a way old story; this MUST be an option to disable this". And ... WT-holly-F ? No, no option at all :/

I **CAN'T BELIEVE** that after more than 5 years there's still NO option to DECIDE what should be the default behavior of the default browser. And when I see the ridiculous patch [1] this implies, I can't believe it even less. What would be the cost of an option in program's preferences ?! 
I'm a developer for 30 years, and I maintained huge applications with tons of parameters and options and I really don't see why it should be "difficult to maintain".


1. https://launchpadlibrarian.net/368070783/nautilus-restore-typeahead-patch.patch