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

What is the intended use case here?

Assuming find does not modify the view, but only scrolls and moves focus and selection, it would be much more natural for keyboard navigation than search, which alters the view and populates it incrementally. But for such a purpose it would need a simpler keybinding, e.g. Space (which would need to be freed from the strange preview).

"Select items matching" on the other hand is quite different.

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

I'd love to have such a feature. With a *fast*, stupidly simple "Tracker-less" implementation: just filter the current folder's item list when more than two characters are typed. Doing that should not take more than 100 miliseconds. After all, Nautilus already has the list of items. Basically similar to typeahead, only better because it behaves like a "filter".

Also tangentically related from a usability standpoint: bug #703629 for the normal Tracker-enabled recursive search feature ("Provide context - allow users to know the path / location from where files and folders in search results come from")

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

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

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

I'm a developer dealing with large source tree's, for me Tracker is completely useless. As soon as I start typing in a directory I'll get 20 matches for the same directory names. That's not helpfull, it's noise.

I also use network drives quite a lot, where tracker doesn't work (and really really shouldn't). Now I don't know how many of you have tried using typeahead find without tracker on network drives, but... the user experience is less than optimal.

Add to this that the current state of things is not simply slow, it is also unpredictable.

Consider the following example: in my home directory, I know I have a folder called "research", and nothing else starting with "r". I want to navigate to it.

With the old typeahead, I would simply open the folder, type "r", and press "Enter". It is not "just" fast: I can do it without looking, and after dozens of times I did it, without thinking. Think of "Tab" and then "Enter" in a shell.

With the new search feature, if I type "r" and then press "Enter", there is a subtle race condition, due to the fact that the "research" folder is opened only if the search was quick enough (or I was slow enough) to let "research" appear in the results.

By the way, on my machine I am usually _not_ slow enough, and I always end up doing a mess. Clearly, as Anders suggested, this is even much much worse on network drives.

So please, I understand that the new search may (?) be useful for some users, but preserving the old functionality should not be that hard.

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

Thinking here, probably some (or many) users are familiarized with current behavior,and probable few of them likes it, so wouldn't be better implement this as configurable feature ?, something like:

[ComboBox or CheckButton] KeyPress Behavior:
 * Filter
 * Search

So users can use it as them likes.

The current situation is just aweful. It is slow and confusing. For instance, if I open nautilus and type V to find the Video directory that is in my home, it will be very slow and show me with no distinction all the video directories of my computer.

If I really need to do a recursive search, I can still do Ctrl+F.

I completely stopped browsing with letters. I only use arrows now. Obviously much slower, and requires interaction but still quicker than the current "find" feature, or mouse.

So, to be clear, Nautilus has Search, which filters results without jumping to any result. It no longer has Find, which jumps to a result without any filtering.  Whereas Find was instantaneous, Search is expected to require up to a quarter of a second or so to display the first results (unless nautilus is built without support for tracker, in which case it will be very slow; this is not recommended). Is this moderate delay bothering you, or are you getting longer delays than that?

We know the presentation of the search results are horrible, but this bug is about potentially bringing back Find in some form. It's very unlikely to be type-ahead Find, though, since in GNOME type-ahead is nowadays consistently used only for Search.

I would say three things mostly bother us (me, at least), in decreasing order of importance:
1) the "moderate delay",
2) the compulsory interactivity of the process (i.e. typing "r" and quickly "Enter" will not open my "research" folder, since I didn't wait for the "moderate delay" to be over - compare with what happens with "tab" in bash),
3) the visual noise - anything popping up which is not related to what I _know_ is in that folder is a (tiny) loss of concentration.

(... all this becomes more frustrating because while I perfectly understand that typeahead users might be a niche, my grandmother will not benefit from a quick recursive search _inside_ the current folder - if anything, she expects a "search" to be in the whole filesystem. But then my grandmother is certainly a niche too...)

If you guys decided that "type-ahead is Search", well, I see only two options
1) you break the most efficient way to browse folders (I'm in for a competition, really) pushing many user to look for another file,
2) you add a nice setting "Make type-ahead look only in the current folder", which re-enables the previous behaviour.

Usage cases that are currently broken:

1. A subdirectory with source code.  This will have a number of subdirectories, each with duplicate files 'Makefile', and 'Makefile.am', etc.  I've got projects with multiple 10,000 files.  If I type 'Mak', I want *this* Makefile.

2. A subdirectory with 1,000s of files.  Typeahead was a quick way to get to the right file(s); search is not.  Especially if there are 100 subdirectories, each with 1,000 files.  Right now your only option is to scroll through 100 pages with a mouse.

3. Subdirectories that are network mounted, or on slow storage, are temporary copies, or otherwise deliberately excluded from tracker.

4. Predictable, fast, repeatable.  The search is not predictable, not repeatable if it's interrupted, and always slower than the time between two keystrokes.

Nautilus is a file manager.  Help me manage my mess of files.

Michael, today I made an effort to see if I could just bear the "moderate delay" and try to fake as nothing had happened in the last months.

I can confirm all the problems already raised, but there are three more I had not considered.

1) I am in a folder with (tons of subfolders and sub-subfolders, including) two subfolders called "Scontrini", "Contributi" and "cookstoves".
I type "co".
After more than one second (maybe my nautilus is built without support for tracker?! I don't know, but I use Debian and the "gnome" package does indirectly depend on the "tracker" package), lots of folders appear. The first are "Scontrini", "Contributi" and "cookstoves"... in this order!
I obviously meant to select "cookstoves", I ignore what is determining the order.

2) I am in a folder containing thousands of files with names such as "MM_DD_hh_mm.out". I want to quickly jump to the last file of a given month, say October. With the old typeahead, I would just type "11" and then press the "left" arrow. Nothing like this is possible now - search looses any spatial representation of content.

3) At some time, I pressed one key and so much stuff popped out that I even forgot which folder I was working in (sorry, I'm not very smart, in particular when I'm tired). I looked at the top of the Nautilus window to look for the current path... and it had disappeared! It reappeared only when I canceled the search. (But this is easy to solve, I guess)

@Michael Catanzaro,

> "Search is expected to require up to a quarter of a second or so to display the first results."

If I want to go to a directory that starts with the letter "e", before I could simply type "e" and eventually a second letter if needed. It was instantaneous. Now this takes a few *seconds* ! And it's not even helping to get all the directories that contain the letter "e" while I just want the one that start with that letter.

So yes, I have longer delays and I don't even have what I want. Plus, if I use the search in a directory that contains a lot of sub-directories, one core of my processor is used at 100%. While I was writing this message, I forgot the search of the letter "e", nautilus freezed when I tried to remove the search.

I seriously can't believe that Gnome developers refuse to include the patch for restoring typeahead (https://bugzilla.gnome.org/show_bug.cgi?id=721968) and still have not provided a suitable alternative.

I stopped using Nautilus long ago and just use command line (tab completion ftw), but I've gotten people to switch to Linux and this is one of the biggest complaints I get.

There are more than enough examples showing how the current search breaks people's workflows and how horribly it fails at actually helping people find files. We're going on 3.16 now and this isn't anywhere in sight?

Things like this is what leads people to use Ubuntu... they care about user feedback and make patches to fix broken (yes, it's broken) functionality.

Really disappointing...

I have to add that this changed behavior is especially annoying when I browse remote file systems with nautilus such as ssh or webdav because the search is much slower there.

I can only underline the lack of understanding expressed by the previous commenters. I recognize that you have legitimate reasons to change the default behavior but the continued ignorance (or refusal?) to add an option to change back to the old behavior is more than a disappointment. There is a quite simple opportunity to make people happy here ;)

for 3.18 we will try to implement https://github.com/gnome-design-team/gnome-mockups/blob/master/nautilus/nautilus-next/search-options.png

OK, better than nothing. So an option "only match the start of the name" would be really easy to add, right?

(In reply to Pietro Battiston from comment #22)
> OK, better than nothing. So an option "only match the start of the name"
> would be really easy to add, right?

I don't know off-hand. Even if it is easy, we don't make UI decisions based on how easy is to add them. Just in case you are expecting that to be upstream =)

I don't think it needs to be an option: we can sort the results such that matches at the beginning of the filename (the best matches) show up at the top of the list, above matches in other portions of the filename.

@Carlos:the fact that the option would be useful to a large number of peple was implicit

@Michael: sounds good. Could we also have that among the best (and even among the worse) matches, items are ordered alphabetically?

I'm attaching an updated patch for Nautilus 3.16.2 to re-implement typeahead.

This is an update to the Ubuntu patch that I'm now using on Fedora 22 Beta.

Just like Ubuntu, it's disabled by default.  You have to enable it in the preferences using dconf-editor: org.gnome.nautilus.preferences.enable-interactive-search

I've QA-ed it for 5 seconds.  It may crash or cause other unintended side-effects (no, they are not bugs...)

Created attachment 303417 [details] [review]
enable type-ahead

re-enable typeahead

(In reply to Berend De Schouwer from comment #27)
> Created attachment 303417 [details] [review] [review]
> enable type-ahead
> 
> re-enable typeahead

Hi, thanks for this patch, however we are going to implement upstream what I said in comment 21 . If you want to provide a patch like that instead of this one, we will welcome it :)

I just updated a patch, I didn't write it.  I needed a solution *now* (ever since 3.8.)  This was the quickest.  Also, a number of CC-es are from duplicate bug reports that specifically mention type-ahead.

(In reply to Berend De Schouwer from comment #29)
> I just updated a patch, I didn't write it.  I needed a solution *now* (ever
Don't worry then, the fix we said will be available in the next version (as any other solution)
> since 3.8.)  This was the quickest.  Also, a number of CC-es are from
> duplicate bug reports that specifically mention type-ahead.
Yes, because type-ahead was the previous solution for this use case.

(In reply to Carlos Soriano from comment #30)
> (In reply to Berend De Schouwer from comment #29)
> > I just updated a patch, I didn't write it.  I needed a solution *now* (ever
> Don't worry then, the fix we said will be available in the next version (as
> any other solution)
> > since 3.8.)  This was the quickest.  Also, a number of CC-es are from
> > duplicate bug reports that specifically mention type-ahead.
> Yes, because type-ahead was the previous solution for this use case.

Reading you, I have the feeling that you think that the proposition you talked in comment 21 is an alternative solution to replace type-ahead for this use case. I disagree.

As mentioned by Berend, a lot of people are from duplicate bug reports that were explicitly asking to restore the type-ahead feature. The type-ahead feature was not only a way to find a file in the current directory, it was about navigation. How this "solution" can improve the situation described in comments 9, 15 and 17?

(In reply to Maxime Chéramy from comment #31)
> (In reply to Carlos Soriano from comment #30)
> > (In reply to Berend De Schouwer from comment #29)
> > > I just updated a patch, I didn't write it.  I needed a solution *now* (ever
> > Don't worry then, the fix we said will be available in the next version (as
> > any other solution)
> > > since 3.8.)  This was the quickest.  Also, a number of CC-es are from
> > > duplicate bug reports that specifically mention type-ahead.
> > Yes, because type-ahead was the previous solution for this use case.
> 
> Reading you, I have the feeling that you think that the proposition you
> talked in comment 21 is an alternative solution to replace type-ahead for
> this use case. I disagree.
> 
yes
> As mentioned by Berend, a lot of people are from duplicate bug reports that
> were explicitly asking to restore the type-ahead feature. The type-ahead
Because the solution we had for this use case was type-ahead... not something different. I expect them to talk about type-ahead and not about a different thing.
> feature was not only a way to find a file in the current directory, it was
> about navigation. How this "solution" can improve the situation described in
> comments 9, 15 and 17?
I'm not sure I understand. Nothing on those comments clash with this solution, and the result will be almost identical.
delay: yes, and it will be "nothing" if we can restrict search to the current view...
spatial navigation: you will have on view just what you are interested for on the current folder. Can't imagine a better spatial navigation.
current path hidden: this is a bug we will fix, and not related to this solution.

Maybe there's something I don't understand then. Let's take a simple example:

Let's say that the current folder contains the following files: Apple, Audience, Ball, Downloads, Elements, Videos. My goal is to go into the Elements directory.

With type-ahead, I can type e followed by [enter]. With your solution, I understand that the view will change to show: Apple, Audience, Elements and Videos. Am I wrong?

But actually, when I wrote my message, I forgot Michael's suggestion. If I understand correctly, that would change the view to: Elements, Apple, Audience and Videos. This is definitely better. However, if I type several letters, the view will change several times: not only some items will disappear but the order will also change.

(In reply to Maxime Chéramy from comment #33)
> Maybe there's something I don't understand then. Let's take a simple example:
> 
> Let's say that the current folder contains the following files: Apple,
> Audience, Ball, Downloads, Elements, Videos. My goal is to go into the
> Elements directory.
> 
> With type-ahead, I can type e followed by [enter]. With your solution, I
> understand that the view will change to show: Apple, Audience, Elements and
> Videos. Am I wrong?

Yes, I hope it's like that (tracker giving more importance to Elements than Audience if you type just e). If not, we will need to fix that in the long run in tracker.
> 
> But actually, when I wrote my message, I forgot Michael's suggestion. If I
> understand correctly, that would change the view to: Elements, Apple,
> Audience and Videos. This is definitely better. However, if I type several
> letters, the view will change several times: not only some items will
> disappear but the order will also change.

It will change, as it changes with type-ahead as well, since it changes for new entered letters. As long as you have the same functionality (or at least almost identical in the usual cases) as type-ahead without even looking at the screen, everyone should be happy with this (as far as I can see).

Carlos, I personally appreciate a lot the attempt to satisfy the "ex-type-ahead users", still I do wonder why we are not able to understand each other. I understand compromises on design choices, but at least requests should be clear.

Type-ahead allows spatial navigation. The brain of some of us likes space.
Type-ahead allows me to jump to the last folder starting with "n" by clicking "o" and then "left".
Type-ahead minimizes visual clutter (both in the sense of "minimal changes to the view" and of "few changes to the view"). The view does not _change_ (as you say) with type-ahead, it only _moves_.

What you suggest does none of this.

It is a _great_ step forward from the current state. I will appreciate it a lot, and I am pretty sure most "ex-type-ahead-users" will use this new functionality and not miss the old one _too much_. So thanks a lot, really, for caring about this.

But that said: no, it is not "the same functionality". Not even if one doesn't look at the screen (and I do look at the screen occasionally!).

Just to be clear: I don't mean to reopen a flame, but your last comment gave me the impression that there was some space for clarification.

On a more practical point: type-ahead was not "just fast", it had no race conditions. Waiting a fraction of second is usually not this huge problem, what is important, for the new functionality to really be useful, is that if I quickly type "m" and then "Enter", _without waiting for the view to be populated_, the first file/folder starting with "m" is opened. Can this be done? Because otherwise even a very modest delay is a problem. This currently bothers me more than the mere time I spend waiting.

(In reply to Pietro Battiston from comment #35)
> Carlos, I personally appreciate a lot the attempt to satisfy the
> "ex-type-ahead users", still I do wonder why we are not able to understand
> each other. I understand compromises on design choices, but at least
> requests should be clear.

I'm just trying to conduct the discussion to something more open, it's not that we don't understand each other I think.
We had type-ahead navigation. That's a solution for one use case.
We removed, and now the current solution is not good enough for this use case.
We are trying to do a new solution for this use case that fits better with the way we want nautilus to be.
I understand that people say "please put back type ahead" instead of "hey, currently we have a use case with no good solution, let's think about something for it and better of what we had and that fits better with the way we want nautilus to be". But we have to think like that, not in specific solutions just because they were solutions.
> 
> Type-ahead allows spatial navigation. The brain of some of us likes space.
> Type-ahead allows me to jump to the last folder starting with "n" by
> clicking "o" and then "left".
Is that a real use case? Can you provide a specific example?
> Type-ahead minimizes visual clutter (both in the sense of "minimal changes
> to the view" and of "few changes to the view"). The view does not _change_
> (as you say) with type-ahead, it only _moves_.

Well, moving is more or less like changing the view. It is true that it has a different level of change, but it still changes. I don't think this is a strong point.

> 
> What you suggest does none of this.
> 
> It is a _great_ step forward from the current state. I will appreciate it a
> lot, and I am pretty sure most "ex-type-ahead-users" will use this new
> functionality and not miss the old one _too much_. So thanks a lot, really,
> for caring about this.
> 
> But that said: no, it is not "the same functionality". Not even if one
> doesn't look at the screen (and I do look at the screen occasionally!).
> 

I think we fix the use case "going to a folder/file in the current directory in a reasonable way/time" that is what I care to, providing solutions to common use cases.

> Just to be clear: I don't mean to reopen a flame, but your last comment gave
> me the impression that there was some space for clarification.
> 

Your comment is fine, no flame at all!

> On a more practical point: type-ahead was not "just fast", it had no race
> conditions. Waiting a fraction of second is usually not this huge problem,
> what is important, for the new functionality to really be useful, is that if
> I quickly type "m" and then "Enter", _without waiting for the view to be
> populated_, the first file/folder starting with "m" is opened. Can this be
> done? Because otherwise even a very modest delay is a problem. This
> currently bothers me more than the mere time I spend waiting.

This is imho the "can be" biggest problem with this solution. I hope it's fast enough, let's see =)

(In reply to Carlos Soriano from comment #36)
> (In reply to Pietro Battiston from comment #35)
> > Type-ahead allows spatial navigation. The brain of some of us likes space.
> > Type-ahead allows me to jump to the last folder starting with "n" by
> > clicking "o" and then "left".
> Is that a real use case? Can you provide a specific example?
> > Type-ahead minimizes visual clutter (both in the sense of "minimal changes
> > to the view" and of "few changes to the view"). The view does not _change_
> > (as you say) with type-ahead, it only _moves_.
> 
> Well, moving is more or less like changing the view. It is true that it has
> a different level of change, but it still changes. I don't think this is a
> strong point.

I like the way Pietro present Type-ahead: it's for spatial navigation, and for people with spatial memory, it is important. Sometimes, I don't remember the exact name of a file, but I remember it is near a file named "Foo", so I go to the file Foo by typing "foo" while watching around to see my file, Usually, I don't need to type the full name of the first file to find the file I was looking for and I finish with the direction keys.

Type-ahead moves the selected file but does not change what is displayed nor the sorting of the files. It is very important for me, otherwise, I have the feeling to be lost when the displayed elements are changing.

Here's another, unrelated, use case: I am in a folder and want to rename a bunch of files. In that case, I use type-ahead to change the selection but I want to see the other files in order to read the name of the next file I need to rename. This can perfectly be done using a mouse but I feel more comfortable using the keyboard.

Anyway, the solution you are suggesting is a real improvement to the current situation and I hope this will be enough to allow me to use Nautilus again. I just feel that Nautilus is going to the wrong direction by removing type-ahead. If I need to do a search in a folder (recursively or not), I prefer to click on a button before or use a keyboard shortcut.

I'm following this discussion for quite a while now and don't really understand this absolute reluctance to reintroduce type-ahead as an option to users that like this kind of solution to the described use case. 

I perfectly understand that you want to have a consistent UI and try to find solutions that you think improves user experience. This gives you every right to set standards and is most probably useful to a lot new users. However, if you use type-ahead for years, you get used to this specific solution. I don't understand why you are so eager to convert these users to another solution as they are already satisfied with what they have and just want to keep it that way. Could you please explain the great disadvantage in offering type-ahead as a (maybe more or less hidden option) for creatures of habit like me? I always liked at free software that nobody tries to dictate me that I now have to adopt to something new that I don't want. Please help people like me or explain me why this is not possible.

Moreover, I want to add one point to the requirements discussion: I always liked at type-ahead that it doesn't clear the view. I would disagree with your assessment that the lower degree of changes in the view isn't a strong point. For spacial orientientation this is (at least for me) much less confusing. Additionally, you keep an overview of the other elements that are present in the directory although they are currently not selected.

(In reply to Carlos Soriano from comment #36)
> (In reply to Pietro Battiston from comment #35)
> > [...]Carlos, I personally appreciate a lot the attempt to satisfy the
> > "ex-type-ahead users", still I do wonder why we are not able to understand
> > each other. I understand compromises on design choices, but at least
> > requests should be clear.
> 
> I'm just trying to conduct the discussion to something more open, it's not
> that we don't understand each other I think.
> We had type-ahead navigation. That's a solution for one use case.
> We removed, and now the current solution is not good enough for this use
> case.
> We are trying to do a new solution for this use case that fits better with
> the way we want nautilus to be.
> I understand that people say "please put back type ahead" instead of "hey,
> currently we have a use case with no good solution, let's think about
> something for it and better of what we had and that fits better with the way
> we want nautilus to be". But we have to think like that, not in specific
> solutions just because they were solutions.

Apparently makes sense, but I'm afraid that if you attribute the words
"use case" a strict enough meaning, there is no space in UI design for
the words "spacial intelligence". This would seem to me quite
paradoxical (and anachronistic, if I think that Google created Material
Design...).

That said: there is no problem of type-ahead "fitting" with the way "we
want nautilus to be". The only reasonable reason I see for removing
type-ahead is the will to reduce code complexity/improve maintainability
("removing a checkbox in the settings" is no more a reason now there is
"only look in current folder"). And since I do not devote my time coding
for Nautilus, I have no right (and no consensus measuring instrument) to
object. But the widely adopted patch reintroducing type-ahead (i.e. in
Ubuntu) at least suggests that type-ahead and the "new nautilus" work
great together.


> > Type-ahead allows spatial navigation. The brain of some of us likes space.
> > Type-ahead allows me to jump to the last folder starting with "n" by
> > clicking "o" and then "left".
> Is that a real use case? Can you provide a specific example?


Yep, see point 2) in my Comment 17. I guarantee that's a "true life"
example. Then, I won't say this specific example happens often (to me).
But yes, I do regularly use letters/digits as a browsing/scrolling device
rather than just as a way to select a specific object.

> > Type-ahead minimizes visual clutter (both in the sense of "minimal changes
> > to the view" and of "few changes to the view"). The view does not _change_
> > (as you say) with type-ahead, it only _moves_.
> 
> Well, moving is more or less like changing the view. It is true that it has
> a different level of change, but it still changes. I don't think this is a
> strong point.
 

If I move a sheet of paper in my hands, I don't consider it as
"changing", and I find it not disturbing at all, i.e. I can keep on
reading its content without any difficulty. But if its content changes
under my eyes, that's another story. Although I am no neuroscientist, I
am pretty sure my brain doesn't care at all about the percentage of
pixels changed, but rather about what they represent logically.

> [...]
> > On a more practical point: type-ahead was not "just fast", it had no race
> > conditions. Waiting a fraction of second is usually not this huge problem,
> > what is important, for the new functionality to really be useful, is that if
> > I quickly type "m" and then "Enter", _without waiting for the view to be
> > populated_, the first file/folder starting with "m" is opened. Can this be
> > done? Because otherwise even a very modest delay is a problem. This
> > currently bothers me more than the mere time I spend waiting.
> 
> This is imho the "can be" biggest problem with this solution. I hope it's
> fast enough, let's see =)


OK, I also hope. Just to understand, what shall we "see"? Who? On which
devices? What if it is not fast enough? Is a proper fix not possible?

It would be sad to have a fix which doesn't fix and come back discussing
here in two years.

(In reply to M. Lang from comment #38)
> I'm following this discussion for quite a while now and don't really
> understand this absolute reluctance to reintroduce type-ahead as an option
> to users that like this kind of solution to the described use case. 
> 

Because we think is not a good enough solution... and I'm sure it has been explained before with all the push back gnome had with this one.

> I perfectly understand that you want to have a consistent UI and try to find
> solutions that you think improves user experience. This gives you every
> right to set standards and is most probably useful to a lot new users.
> However, if you use type-ahead for years, you get used to this specific
> solution. I don't understand why you are so eager to convert these users to
> another solution as they are already satisfied with what they have and just
> want to keep it that way. Could you please explain the great disadvantage in
> offering type-ahead as a (maybe more or less hidden option) for creatures of
> habit like me? I always liked at free software that nobody tries to dictate

I understand the "habit" point. Really, I'm not sure how we can go forward in a reasonable pace without changing the habits of the users (and for what I saw, others OS neither) or without just doing a fork. I hope the Gnome experience will stabilize more and more.

To make clear, an app provides solutions for problems, don't dictate anything at all. You chose that app for your needs. And we take decisions to change apps to make it better in a long term. So if if you feel it dictates you, it's one of the basis of our app development I'm afraid, at least for Gnome3.

But probably we should stop this kind of discussion on Bugzilla, it's a little off-topic or too general for this bug report. You can reach us on IRC or in forums for off-topic.

> me that I now have to adopt to something new that I don't want. Please help
> people like me or explain me why this is not possible.
> 
> Moreover, I want to add one point to the requirements discussion: I always
> liked at type-ahead that it doesn't clear the view. I would disagree with
> your assessment that the lower degree of changes in the view isn't a strong
> point. For spacial orientientation this is (at least for me) much less
> confusing. Additionally, you keep an overview of the other elements that are
> present in the directory although they are currently not selected.

(In reply to Pietro Battiston from comment #39)
> (In reply to Carlos Soriano from comment #36)
> > (In reply to Pietro Battiston from comment #35)
> > > [...]Carlos, I personally appreciate a lot the attempt to satisfy the
> > > "ex-type-ahead users", still I do wonder why we are not able to understand
> > > each other. I understand compromises on design choices, but at least
> > > requests should be clear.
> > 
> > I'm just trying to conduct the discussion to something more open, it's not
> > that we don't understand each other I think.
> > We had type-ahead navigation. That's a solution for one use case.
> > We removed, and now the current solution is not good enough for this use
> > case.
> > We are trying to do a new solution for this use case that fits better with
> > the way we want nautilus to be.
> > I understand that people say "please put back type ahead" instead of "hey,
> > currently we have a use case with no good solution, let's think about
> > something for it and better of what we had and that fits better with the way
> > we want nautilus to be". But we have to think like that, not in specific
> > solutions just because they were solutions.
> 
> Apparently makes sense, but I'm afraid that if you attribute the words
> "use case" a strict enough meaning, there is no space in UI design for
> the words "spacial intelligence". This would seem to me quite
> paradoxical (and anachronistic, if I think that Google created Material
> Design...).
> 

Sometimes I think too strict, so maybe I'm wrong here? I don't know. I lost a little with your words now :)

> That said: there is no problem of type-ahead "fitting" with the way "we
> want nautilus to be". The only reasonable reason I see for removing
> type-ahead is the will to reduce code complexity/improve maintainability
> ("removing a checkbox in the settings" is no more a reason now there is
> "only look in current folder"). And since I do not devote my time coding
> for Nautilus, I have no right (and no consensus measuring instrument) to
> object. But the widely adopted patch reintroducing type-ahead (i.e. in
> Ubuntu) at least suggests that type-ahead and the "new nautilus" work
> great together.
> 
> 
> > > Type-ahead allows spatial navigation. The brain of some of us likes space.
> > > Type-ahead allows me to jump to the last folder starting with "n" by
> > > clicking "o" and then "left".
> > Is that a real use case? Can you provide a specific example?
> 
> 
> Yep, see point 2) in my Comment 17. I guarantee that's a "true life"
> example. Then, I won't say this specific example happens often (to me).
> But yes, I do regularly use letters/digits as a browsing/scrolling device
> rather than just as a way to select a specific object.
> 

I think that's a solution I wouldn't like for this specific use case... even if it works for you.

> > > Type-ahead minimizes visual clutter (both in the sense of "minimal changes
> > > to the view" and of "few changes to the view"). The view does not _change_
> > > (as you say) with type-ahead, it only _moves_.
> > 
> > Well, moving is more or less like changing the view. It is true that it has
> > a different level of change, but it still changes. I don't think this is a
> > strong point.
>  
> 
> If I move a sheet of paper in my hands, I don't consider it as
> "changing", and I find it not disturbing at all, i.e. I can keep on
> reading its content without any difficulty. But if its content changes
> under my eyes, that's another story. Although I am no neuroscientist, I
> am pretty sure my brain doesn't care at all about the percentage of
> pixels changed, but rather about what they represent logically.

Good example. It made me understood the difference.

> 
> > [...]
> > > On a more practical point: type-ahead was not "just fast", it had no race
> > > conditions. Waiting a fraction of second is usually not this huge problem,
> > > what is important, for the new functionality to really be useful, is that if
> > > I quickly type "m" and then "Enter", _without waiting for the view to be
> > > populated_, the first file/folder starting with "m" is opened. Can this be
> > > done? Because otherwise even a very modest delay is a problem. This
> > > currently bothers me more than the mere time I spend waiting.
> > 
> > This is imho the "can be" biggest problem with this solution. I hope it's
> > fast enough, let's see =)
> 
> 
> OK, I also hope. Just to understand, what shall we "see"? Who? On which
> devices? What if it is not fast enough? Is a proper fix not possible?
> 
> It would be sad to have a fix which doesn't fix and come back discussing
> here in two years.

Who? Us, we have to implement the solution and try how it works.
Which devices? All I hope, we will need tests.
What if it is not fast enough? It's an open question. We will think if it is the way to go anyway since it's better than what we have or is not good enough.
Is a proper fix not possible? I don't know yet, that's why "we will see".

But no, it won't be sad, we are just trying to improve, failing is a valid outcome, so we can do something better.

(In reply to Carlos Soriano from comment #40)
> (In reply to M. Lang from comment #38)
> > I'm following this discussion for quite a while now and don't really
> > understand this absolute reluctance to reintroduce type-ahead as an option
> > to users that like this kind of solution to the described use case. 
> > 
> 
> Because we think is not a good enough solution... and I'm sure it has been
> explained before with all the push back gnome had with this one.

A link would be much appreciated. I follow this since a while and never even considered there could be any argument other than "to reduce code complexity and increase maintainability, it is sometimes OK to sacrifice features [assumingly] only used by a niche of users" (perfectly in the GNOME 3 spirit, but without the possibility of resorting to a plugin providing such features).

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.

For whoever is following this hoping for a return of typeahead: I had a long chat with people in #gnome-devel (I asked if I could publish the logs and didn't really get any positive answer, but feel free to ask me in private), and basically:

- some developers/designers think hierarchies made of folders are something old-fashioned, a cool home directory has an almost flat structure, and in order to not be old-fashioned, nautilus must (and rightly does) put more importance on the content (including names of files) and less on the path to the content - this "semantics" vs. "organization" reasoning seems to have been pretty crucial in the recent design decisions for nautilus; users relying on non-trivial folder structures could possibly live better by just changing file browser, since by the way they (the developers/designers) don't consider nautilus as unreplaceable in the GNOME3 ecosystem - it's just one of the many "apps",

- other developers recognize there are several use cases and would like nautilus to accomodate them to the extent that it is feasible, but they consider keeping two very different search/navigation keyboard-driven methods as not feasible due to the code complexity it implies. Still, they (in particular, Carlos) will try to fix what can be fixed. Something that was already fixed in master was the "look only in the current directory" option. Something that will probably be fixed soon is the option "consider only files with the pattern at the beginning of the name". Something that will have to be faced next is the race condition ("m" and then "Enter" should act unconditionally on the time the view takes to get populated).

I personally lost any hope of convincing the devs to come back on their steps, since the "code complexity" argument is in the end the decisive one, and there is not much a non-dev can question about this. And by the way, they clearly stated that the number of users that show up in bug reports unsatisfied with the decision is not a very relevant argument (quoting verbatim, "Free software is not a popularity contest, and this kind of stuff attracts a very specific kind of people").

While I'm trying to convince Debian maintainers to adopt the Ubuntu patch, at least until the fixes mentioned above are deployed, so far I didn't get a positive response on that side neither.

Three cases where I definitely don't have a flat structure, that I use often:

1. Music

One folder per album.  This is not going to change as long as multiple artists cover the same song, and multiple artists have a "piano concerto no. 5"

2. Source code / development.

For example, Firefox (31) has 1077 Makefiles and corresponding subdirectories (not counting directories without a Makefile!)

Even small projects have src/Makefile, lib/Makefile, tests/Makefile and /Makefile.

3. Photography.

I tend to take 1,000 photos at a time, and then edit them.  My current go-to camera has a shutter count of 50,000; and I haven't had that one that long.

I'm sure there's more use cases.  There's a reason I don't do everything on a tablet.


In Photography type-ahead is useless, btw.  DSC001, DSC002, ...  but then so is search.


I'm not against getting useful functionality in a way other than type-ahead.  However, currently the alternative doesn't exist, so I shall continue to patch my copy of Nautilus.  Maybe try a COPR on Fedora.  Maybe have a look at Nautilus master.


I'm also pretty sure the devs won't come back on their steps.

People can have their opinions, and even then I think that opinion was referencing new apps like gnome-photos and gnome-documents and the future (not Nautilus future), but what matters at the end is the opinion of the people working on Nautilus, and for now it's mostly maintainers, and I completely agree Nautilus should work excellently with the hierarchy of the file system, because for that reason it is a file manager and not gnome-photos/gnome-documents or whatever.

So before assuming, please be cautious.

"I'm also pretty sure the devs won't come back on their steps."
Then there is no point commenting here =) . For this kind of conversation/discussion/comments please use IRC or forums.
Keep here only technical comments.
Thanks

(In reply to Carlos Soriano from comment #46)
> People can have their opinions, [...]
> what matters at the end is the opinion of the
> people working on Nautilus, and for now it's mostly maintainers[...]
> 
> So before assuming, please be cautious.

OK, sorry. Actually, my understanding is that the opinions of designers mattered a lot for removing this feature (years before any reasonable replacement was/will be present), maybe because at the time this decision was taken there was no maintainer. But if I look back at the chat then you're perfectly right that the two designers which were behind such decision were not among those advocating flat home dirs, they actually think nautilus should work well for anybody.

Sorry for the noise. Which is always a risk when public information about decisions is second/third hand... your promised blog post will certainly work better ;-)

I just did a system upgrade, and type-ahead is disabled also in the  FileChooserDialog. OK, no panic. Carlos, could you shed light on a couple of aspects related to the discussion here?

1) Do the options we are discussing about ("Search subfolders", "only files beginning with pattern" and possibly others) naturally apply to search in the FileChooserDialog? The logic answer would be "yes", but then the fact that the configuration dialog (in the mockup) is part of nautilus made me want to double-check (by the way, the FileChooserDialog search has a "Path" column, which in principle is nice, but it is too small to make it useful without resizing both the window and the "Name" column).

2) Why is the search not activated by just typing (one has to click on the lens)? It doesn't seem to me it would clash with any other use of the keyboard. And... well, clearly for keyboard users this makes a difference.

Note that in GTK+ 3.18 the behavior has changed so that typeahead is the equivalent of Ctrl+L to focus the location entry, then you get standard tab completion in the location entry. It's definitely better than the 3.16 behavior, but I'm not sure why we're doing it instead of the usual type to search pattern. That was tried at some point recently, but I was told that "didn't work well" in the GtkFileChooser.

By the way: when I save from Evolution instead the lens is not even there (and typeahead is not working anyway)... is this a bug in Evolution? The keyboard is completely useless there (when the text field is not selected).

this is not a forum. Discussing the file chooser in nautilus bugs is not likely to help you find answers, and is going to make it harder to make progress on the nautilus bug.

The usage regression is common, and I took it as granted that the fix should be common too (at least concerning my point 1, the gsettings options) to avoid both code and user interfaces duplication. But if Matthias you know that I'm wrong, and that attempting a unified view of the problem is useless, just state so and let's open separate bugs.

Releasing the 3.18 target since some improvements were done and they are working nice and seems to go on the right direction.
There are more improvements to come, hopefully by 3.20 we can see how everything works together and mark again another target if the conclusion is that works well enough for all use cases or not.

I'm cleaning bug with patches (there's nothing worse than leave contributors with patches languishing)

This bug has a patch that depends on whether we want type ahead or not. Since in 3.18 and 3.20 we improved the way search is done and options for do recursive search were added, I think we can close this one and the patch as well.

We can still improve it to give even more preference (as in fast) for files in the current directory, but I'm happy how it is going and I think is the way forward. Even more since we are going to rework the views using the new gtk+ widgets...

So closing for now as obsolete, just for cleaning up a little more bugzilla...

Do not add non-technical comments. See comment 46. Thanks.

A lot has been discussed in this bug, but very little has been implemented so far. The current search is still actively working against me every time I use nautilus. Since I use started using Jetbrains products, I have completely stopped manually searching folder structures and tree views, as their shift-shift-search and fuzzy-type-ahead work so well. I actually kind of like to have a proper search directly available as soon as I start typing, but the search latency completely breaks it for me.
Using the search on an SSD-only system configured to only search the current folder still has enough delay to prevent me from quickly pressing enter, when I know the search query will match exactly what I want.

For me, quite a few others as well, the search feature is more then just finding files, but in many cases its basically a short cut. I know the file name, I know where it is, but I don't want to manually navigate to it, so I search for the minimal but unique term, that finds the file. Exactly how I search for applications in the app overview or for history entries in Firefox's URL bar. These searches feel instant, even if they take a moment to process. When the Firefox URL bar takes a moment to execute the search, it will finish the search query and then open the page, when I pressed enter already. When I press enter too early in Nautilus, the searchbar just disappears as if I never searched anything. Even IntelliJ's shift-shift global search is faster than Nautilus' "simple" File search. A non-recursive search in Nautilus should be as fast as type-ahead. The first thing the search does, should be to query the currently open folder for file name matches (recursive search or not), in order to have a first result as quickly as possible and in the best case, it's actually the file I wanted.

Should I open a new bug for this or is this a reason to reopen this?

Yes, that's a different bug, as you mention current folder search should be as fast as type-ahead. We are looking into that for 3.28 as part of a GSoC project, so not need to file a new bug report.

(In reply to Phillip Schichtel from comment #57)
> Using the search on an SSD-only system configured to only search the current
> folder still has enough delay to prevent me from quickly pressing enter,
> when I know the search query will match exactly what I want.

Just right. If you are working on networked resources it even locks up nautilus for minutes without even displaying the desired file at the end. If you accidently typed a letter for jumping to the desired file (as everyone usually would do and has done before) and the search cleared the view, there is also no way back. You have to go back to the target directory from scratch to recover. "Back" does not work either then.

This new behavior is not just inconvinient, it also hardly breaks usability in some cases. It makes the responsiveness look like a complete application crash if you just wanted to highlight a file without scrolling threw thousands of files.
This everytime forces me to popup the old native console for just quickly open that specific file wich is completly nuts.

It's just completly broken by design.

(In reply to Jan-Jonas Sämann from comment #59)
> If you are working on networked resources it even locks up
> nautilus for minutes without even displaying the desired file at the end.

That sounds like a bug. Recursive search is supposed to be disabled on network locations. Unless you have explicitly enabled it in the Prefetences dialog. If your preferences are for recursive search are "never" or "local only", and it still locks up on network locations, please file a bug report with the steps to reproduce, so that developers can look into it. Thanks in advance.