Slight correction. Typing just "a" didn’t complete under 4 minutes and then I killed it (it was spinning two CPU cores). Searching for "ab" takes 8 seconds.

Tobias: Please keep comments technical and do not get personal by criticizing particular developers for changes that you describe rather generically. 
Also see https://live.gnome.org/CodeOfConduct for how to write comments.

André, as someone looking at git log of nautilus you sometimes can’t help but feel bewildered how things that were big technical achievements from years of development and community collaboration are deposited in the wastebasket like it’s nothing (I didn’t want to write »are trashed like that«, because that would perhaps be a trigger word for you).

You feel like a voice in the wilderness. There’s seemingly no place for feedback  and peer review anymore.

There’s one guy who never replies on bugs, never lays out justifications and explanations, never responds on mailing lists. Basically a phantom.

And then you and ovitters swoop in and silence whoever dares to make general remarks. I don’t think I was disrespectful. I don’t think I even criticized anyone personally.

But if constructive criticism is forbidden in Gnome, I guess I’ll leave and don’t bother anymore. Maybe Redhat can sort out QA without outside help. Gratis help.

First of all, as you are well aware this is a work in progress and there is still more to do before 3.6. Now, a few comments about each item.

1.

We are currently changing nautilus to allow using Tracker by default for locations indexed by Tracker and a filesystem search for locations not indexed. Nautilus will build with a Tracker dependency by default unless --disable-tracker is used. That is strongly not recommended. Search is going to kind of suck without it.

That said, we have some ideas on how to make search a suck a little less when you decide to roll your own Nautilus without Tracker support. We can prioritize the results found in the current directory and show them immediately. There is no good reason why this can't be as fast as type ahead find was.

But again, this is a fringe case to accommodate people who want to avoid the default search engine.

2.

There is no reason why we can't make the selection process even better than it was with type ahead. Type ahead was really ineffective unless you were absolutely sure what the name was. And that is far less common than you may think. Having a fuzzy matching and potentially on more than just the filename we can make this much more effective .

To accommodate the select a file in context use case we can do a few things. One of them could be to ensure that a file selected while in the search results view is still selected (and in view) when the search is cancelled.

I don't know exactly what problem you are having with keyboard navigation but I can't imagine anything is conceptually different in the search results navigation.


To part of your more general point, aside from the rudeness. We are hoping to make finding files easier for every class of user whether they be frequent files, spring cleaners, or no filers. Those are all real world scenarios. I am confident we can keep Nautilus effective for people like you who seem to know and remember exactly what they are looking for by case sensitive filename within thousands of available files. That is a pretty easy case to handle. And yes, at this particular moment on the unstable path towards 3.6 we have regressed there and help would be appreciated. But the aim is to have that working well. As well as handling a multitude of usage scenarios that we completely failed to cover before.

Alright, this got the ball rolling. Please excuse my rudeness (or however my tone should be classified, I would call it benign irritated bewilderment), but it managed to entice you to respond for once. In that sense »Mission accomplished«. And I like how you responded. Thank you.

About 1. (the slowness): That’s cool and I anticipated something along those lines (i.e., not done yet, should get faster). And I’ll prod Ubuntu into packaging tracker as a dependency if that’s what’s coming. The problem is that single keystroke trigger. The slowness just catalysed the surprise.

BTW, did you know that gnome-search-tool hooks into »locate« to retrieve initial results faster? Could this be used as a fallback to tracker as well? AFAICT modern distros have mlocate databases on by default? Gnome-search-tool is pretty much instant here even without tracker.

But, what about NFS? More below.

About 2. The main problem is, the previous behaviour (type-ahead selection) was not recursive it was limited to the current view, it was a fundamental ingredient in swift keyboard navigation, it was a method of selection not of searching, and it matched what is common in other file managers (not least of which Windows Explorer). It was something entirely different from search.

Now there a several phenomena that lead to a loss of functionality

Very often you do »just know« what you need in the current directory, and you know the sequence of steps you have to take to reach your destination.

My real life example is this. My boss sends me an email »Can you send me a quick render of ALAF?«.

Now I know where the file I need is, I navigate to the right folder, but once I’m there it’s just one among 214 other files. So before I would type »ALAF«, Ctrl-C, navigate somewhere else, Ctrl-V

This is the folder structure: http://paste.ubuntu.com/1097128/

It is a subtree of a humongous NFS network drive with 20 TB of stuff, home directories, databases, random science stuff. You cannot possibly crawl that with tracker, you cannot possibly traverse that with a search. Most of the tree is forbidden to you anyway.

Anyway, if I were to type »ALAF« here it would replace the current directory and give me something like this after a long wait:

towolf@lupin:/kyb/agbu/data/face-database/face-data/classic$ find -iname "*ALAF*"
./ALAF263.head
./ALAF363.head
./check/ALAF263check_c.rgb
./check/ALAF263check_s.rgb
./check/ALAF363check_c.rgb
./check/ALAF363check_s.rgb
./matlab/ALAF263.mat
./matlab/ALAF263.obj
./matlab/ALAF263.png
./matlab/ALAF363.mat
./matlab/ALAF363.obj
./matlab/ALAF363.png
./obj/ALAF263.mtl
./obj/ALAF263.obj
./obj/ALAF263.rgb
./obj/ALAF363.mtl
./obj/ALAF363.obj
./obj/ALAF363.rgb
./orig/ALAF263
./orig/ALAF263.color
./orig/ALAF363
./orig/ALAF363.color
./orig/orig_heads/ALAF263.head
./orig/orig_heads/ALAF363.head
./png/ALAF263.png
./png/ALAF363.png
./png/orig/ALAF263.png
./png/orig/ALAF363.png

And then I still have a problem, because I would have to select ALAF263.head in a list of 28 files. And I would have a scrolling view with thumbnails because many of those are images. So I have to scroll and visually search again.

Another problem is, I cannot quickly navigate to a folder like /kyb/agbu/data/face-database/face-data/classic from my $home in /kyb/agbu/towolf.

Before, that would have amounted to Backspace, da↩, fac↩, fa↩, cl↩, ALAF↩

But now I cannot even get there. If I go up from my home directory, there’s a bottomless abyss of 20TB of files. Before I just had to type "data↩". 

And once I’m in my destination I cannot highlight the file I want in that long flat list.

I guess that’s enough for now.

One more thing after rereading your comment, Jon:

Recursive fuzzy matching can be very bad in certain contexts. I think that’s what I wanted to show with my use case.

Created attachment 219062 [details]
Screencast comparing g-s-t and nautilus

Here’s an informal comparison of gnome-search-tool (using locate) and nautilus (without tracker). Just FYI.


What I think, looking at that video: The main thing I don’t agree with, even if you reorder the results to give precedence to the current directory, if you manage to maintain the selection, etc. Why would I need to hit tracker, hit the icon and thumbnail caches, hit the fs caches and churn everything to pull in 1300 hits, to populate a result list of 1300 icons, when the only thing I wanted was do descend into the "data" subfolder?

There must be a distinction, yes?

In response to comment 5:
It isn't a problem because we're not going to be stupid about the search results. They will be prioritized or ranked. And the current directory would certainly have higher priority than something far from you.

The rank algorithm is to be determined. But I think it would involve at least:
distance/proximity, time of use/modification, and text match score

Using that kind of system allows you to show results close by quickly. And should not be a problem in the case you cite.

Regarding how often I respond. I responded here despite your tone because you identified current technical deficiencies. I respond when I think there is value and there is a chance the discussion can be productive. Thank you for keeping it so after a bit of a shaky start there. There is a lot to do.

(In reply to comment #8)
> It isn't a problem because we're not going to be stupid 
> about the search results.

Fair enough. While this sounds incredibly handwavy to my ears I’ll sit back and see how this pans out in the coming months. 

I still cannot reconcile this model with my use of a file manager and there are many corner cases (NFS, SSH, and FTP mounts, ambiguous file names, staleness of indexing aspects, questions of scale, misalignment with the user’s mental model, etc). I just hope that come September this will not be declared again as set in stone and as designed according to a vision. Of course visions can provide revitalizing impetus to a project (and nautilus needed some), but there are real world contraints as well.

Pray allow me one humble remark. It’s hard for me to grasp why some use cases are deemed as fringe-like special cases (e.g., a large chunk of researchers in my institute is using Linux-cum-Ubuntu-cum-Gnome-cum-Nautilus labouring daily with countless files in obscure formats and various storage locations) while other use cases like touch control are emphasized so much and extolled as central, when in actuality those are much more fringe-like (I’m not aware of a single touch device that ships with Gnome on it). Is this perhaps a question of business orientation?

The only thing I said was a fringe case is the one where nerds build nautilus in a way that actively disregards the way we expect it to be built. We aren't going to spend a lot of time making search not suck if you don't want to use the search technologies we require. So I don't know what you are going on about.

This is now way off topic for a bug report.

> This is now way off topic for a bug report.

True. Back to strictly technicals matters.

In the past hour I looked at tracker and wrote to the git master packaging nerd (sic) in Ubuntu and asked him to build against tracker.

In the meantime I installed tracker on my laptop and found that it’s very hard to see how tracker helps with the issues I identified above.

In the huge NFS mount scenario tracker would not help, because tracker by default only recursively indexes the common »XDG_*« directories. Everything outside of my home and everything not in XDG_* is terra incognita to tracker.

In the keyboard navigation case I hit the problem that tracker returns zero results for »data«. This is because »data« is actually a stop word in /usr/share/tracker/languages/stopwords.en. So, to recapitulate, if I am in ~ and want to go to ~/data with the keyboard and type »data« there would be an empty window? Or are you saying that the tracker query (a) would be run in parallel with (b) a standard directory walk and (c) enumerating the current directory listing in memory? And those three would be aggregated and ranked? And ~/data would be at the top of the list, eventually, for me to press Enter?  I suppose, that /could/ work conceptually.

So in spite of almost 1300 files containing »data« in their names, tracker returns none of those. I suppose that means I have to wait longer. Maybe the aggregation should also really include the mlocate database then as source c). And those sources would return results asynchronously and at interactive latencies? I’m just trying to understand how this can be implemented to have no loss of functionality.

(In reply to comment #11)
> Or are you saying that the tracker query (a) would be run in
> parallel with (b) a standard directory walk and (c) enumerating the current
> directory listing in memory? And those three would be aggregated and ranked?
> And ~/data would be at the top of the list, eventually, for me to press Enter? 
> I suppose, that /could/ work conceptually.

Yes, the plan is implementing something similar to that. Ideally we could be smart and selectively enable engines depending on the current directory (this would be useful e.g. on network mounts).
See also bug 680137 for a start of this.

> So in spite of almost 1300 files containing »data« in their names, tracker
> returns none of those. I suppose that means I have to wait longer.

If you just installed it, it will take a bit to index all your data.

Salve Cosimo,

(In reply to comment #12)
> > I suppose, that /could/ work conceptually.
> 
> Yes, the plan is implementing something similar to that. Ideally we could be
> smart and selectively enable engines depending on the current directory (this
> would be useful e.g. on network mounts).
> See also bug 680137 for a start of this.

I just saw that. How many sources are we talking about? Only directory walk and tracker? Or also memory and possibly mlocate?
 
> > So in spite of almost 1300 files containing »data« in their names, tracker
> > returns none of those. I suppose that means I have to wait longer.
> 
> If you just installed it, it will take a bit to index all your data.

Actually it’s completely crawled. It indexed 18000 files and stopped. But »data« is a stop word. It’s explicitely excluded from the index. I guess that’s because tracker has a very different foxus than what I’m talking about. That is, natural language search vs. finding and highlight file names.

Vorschlag zur Güte, would it be a compromise to first flesh out search fully, but only behind the *very prominent* attractive button, and in the meantime to go back to type-ahead selection as we had it before? 

Right now there’s a lot of »Jank« in that as Chromium people call it, perhaps the switch for natural typing can be made later?

Ähm, and when I try to paste files with Ctrl-V, instead of pasting, it pastes the URIs into the search field and proceeds to search for that string.

This whole thing needs work.

cf. bug #680159

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

Please.. When change feature of programs like this..
Don't remove regacy features. Give us the right of choice.

I think this is too dogmatic!

I feels when using gnome3, Developers seems don't care users that aleady using legacy feature.

You can think some UI changes is really good. But.. You are not the god.
Some people has really critical inconvenience about that.

Example, Now, recently trend is touch frendly. But. Many desktop computers are still using mouse point. So. mouse moving space is more larger than previous.

IN GENERAL:
If you have a technical point that actually refers to the *specific* change that was introduced by *this* bug report, okay.
If you have generic/general comments about technology development or want to express vague disagreement without any *specific* arguments (like the last comment) then please go to a forum instead. It is NOT welcome in a technical bugtracker, plus creates bugmail for everybody. 
If you disagree, feel free to contact bugmaster@gnome.org .

André Klapper//I'm sorry for that.
I understand.

(In reply to comment #5)
> Another problem is, I cannot quickly navigate to a folder like
> /kyb/agbu/data/face-database/face-data/classic from my $home in
> /kyb/agbu/towolf.
> 
> Before, that would have amounted to Backspace, da↩, fac↩, fa↩, cl↩, ALAF↩


I think this is the most important point. This is a use case that must not be broken. It is not a matter of finding a file/directory in a huge list as has been evoked in previous comments. It is a matter of browsing efficiently. This can be used for files that currently appear on screen just because typing two letters is often way more efficient than using the arrows to go down twice and right once. So you cannot claim that it's only used by people that know the exact name and case of their files.

(In reply to comment #21)
> > Before, that would have amounted to Backspace, da↩, fac↩, fa↩, cl↩, ALAF↩
> 
> I think this is the most important point. This is a use case that must not be
> broken. It is not a matter of finding a file/directory in a huge list as has
> been evoked in previous comments. It is a matter of browsing efficiently.

And... This is actually what a *file browser* is for, as opposed to a file search engine UI. Nautilus can become a file search engine UI but it is still primarily a file browser and many people will continue using it that way, and probably switch to better alternatives if it doesn't fit anymore.

Many people in professional context use shared network drives and hierarchically organized data, sometimes with quite meaningless file names (the hierarchy of the files is first and foremost). It includes scientific matlab users, web developpers, sales people. They *need* a way to efficiently *browse* files. They often don't need to search them because they know the hierarchy by heart.

(In reply to comment #4)
> To accommodate the select a file in context use case we can do a few things.
> One of them could be to ensure that a file selected while in the search results
> view is still selected (and in view) when the search is cancelled.

Is there a bug report to follow?

(In reply to comment #8)
> search results. They will be prioritized or ranked.

Is there a bug report to follow?

Hello, 

I want to say that I feel the same that Tobias. I think you [developers] are doing a great job with gnome. Thank you a lot, for real.

But sometimes new features need some tutorials to explain right how it works or at least leave it live with legacy solutions for a while. I'm sure that they are powerfull solutions but now well explained maybe...

Said this. I will try to be constructive. 

When I search for some Music in my "directory organized" "Music folder". I just type the artist. This case "Rosendo", so I type "Ro". It normally takes me to the folder "Rosendo" and inside of this folder I have each album separated. 

This is my way of organize. Maybe is wrong or maybe is right but it's my way.

The problem now is that I can get "Rosendo" for several folders and subfolders and I really don't know what file pertains to what album. For me it's frustrating to see all my organization work to flatten to just a list of files and folders. Take apart that it does not finishes to search, sure it will improve but anyway it works in a way I don't want.


Another example. 

I have a folder called "Projects". Here is where I store my general proyects, But I have also a folder called "Projects" for each customer. Say "Seglan/Projects". When I search for the Projects folder I get a lot of things not even related with what I'm searching in this case.
I can find something like "Future Projects", "Abandoned project" and so on. I just wanted to not search for a list of customers to really find the folder "Projects" that is on the root folder... It takes me a while. You should imagine.


Last one. "Documents", if I search just for the "Documents" folder just typing "Doc" or even "Documents" it starts to search for a lo of files called documents. I have lots of folder documents for each of my projects, but I just want to go to my /home/gaguilar/Documents folder... It makes me search by hand this folder... It's at least not optimal.


So I propose creating something like tags. Like in showwell. It will work better than searching this way. Because when you tells nautilus to search for a tag you know you are searching for a tag. And you can use tracker to search tags inside files, and "JIT tags" created from full text searches/indexes.

I mean, leave usage simple where it needs to be simple. And use "advanced" modes for the people that want this kind of tagging. 

My parents will love it. They don't know where to store things, so it's nice to just type and gnome will find it. That's great guys! 

But for experienced people can get us mad if it's not explained, useful and really fast.

Leave me finish with some examples:

   1.- Shotwell - it has tags and works great. Let's get what's is working...
   2.- Banshee/Rythmbox - I think it's something similar what's is happening here. It constantly updates your library. But has someone thought that maybe you don't want reorganize your library? I use Audacious because I have my own organization already done. And don't want others to think for me how it will be better to organize. So I just drag and drop what I want to hear instead searching for the album.

   3.- new Documents gnome app - Maybe I don't know how to use it. But last time I checked it was not useful because it mixes my hobby documents with my work documents and I don't know where is what, what version of the document is showing and so on. The same problem will be brought to nautilus if we just bring this kind of search to the main screen of "Personal Folder".

   4.- Twitter. Is best example for a tag system that works right. You tag what you want but there are systems to organize these tags. Is just great.

Do I emplained my self?

I think you want to flatten directory structure of our desktops and that's right but you will need to explain how it's supposed to work.

Thank you a lot. 

I would like to colabrate more but I really have not time to write some code. I will try anyway soon. :D

(In reply to comment #23)
> (In reply to comment #4)
> > To accommodate the select a file in context use case we can do a few things.
> > One of them could be to ensure that a file selected while in the search results
> > view is still selected (and in view) when the search is cancelled.
> 
> Is there a bug report to follow?

I now filed https://bugzilla.gnome.org/show_bug.cgi?id=680849

> > search results. They will be prioritized or ranked.
> 
> Is there a bug report to follow?

https://bugzilla.gnome.org/show_bug.cgi?id=680163

Cosimo, would you, as the maintainer, address the particular problem raised in this bug, please?

That search isn’t fleshed out yet is orthogonal to the problem that type-ahead within the list of files was killed.

I’ve endured this for over a week now, at home and at work, and it’s really painful[0]. Can you roll back the type-ahead changes for now?

What you guys attempt to do is too much for one release at any rate. This is a kind of breadth-first revamp that amounts to mutilation of a core part of Gnome.

So even if we are broadly sympathetic with your intentions of a need to revamp, the usage patterns of nobody will remain unscathed in this cycle [1][2]. This leads to bad vibes anywhere you look. I just don’t know how much of a iota you guys give about bad vibes.

Why would you proceed on the good word of one expert who is confident that things will work out for anybody, when there’s nothing but rejection anywhere you look? And as I said, please don’t throw the baby out with the bath water!


[0] internal monologue: »No, I shouldn’t type here, dammit, I have to scroll 
                         with the mouse. Steady, I’ll find this soon enough…«
[1] https://mail.gnome.org/archives/nautilus-list/2012-July/msg00035.html
[2] http://lwn.net/Articles/508532/

I agree with Tobias, search should be complementary to type-ahead file selection, not replace it. The key problem for me is that it goes way beyond type-ahead current-dir-only search because (if I understood it correctly) it's recursive by default.

IMHO this is bad, it doesn't provide the same functionality, it makes it worse -- it'll be slower and it will show more results than needed, which will be very distracting for this particular use case (which is much more usual to me than recursive file searching, YMMV).

I believe search as proposed should be explicitely activated by the user via a keyboard shortcut (ctrl+s?) to handle the "I have no idea where file XYZ is located, please find it for me" scenario instead of the "I know there's a file XYZ on the current directory, take me right to it" one.

Just my $0.02.

How you guys go about it is not relevant to my comment. I would just like this to happen:

When I type a name of a file in nautilus and if that name is in the folder I am viewing then I want the representation of that file to be highlighted so then I can easily perform a action on that file.  

Also I want to be able to use the arrow keys to select adjacent files. It's rare that I know the exact name of the file, but it's _very_ _very_ common that I know the first few letters of the name so that I need to still navigate with the keyboard to narrow down the results.

I don't want to have it select items in other folders. Context is _everything_ and to bring in results from other folders is confusing since the chances of them be relevant is extremely small.

This is looking for a file I know about. It is not 'search'. 'Search' is looking for something I don't know about.  

That's it. That's all I want.


A few comments:
* mlocate sucks. The index is generated by cron job in the evening. If the file has been created since then then it's not going to be found.  Depending on it is really weird and broken since users expect the file manager to be realtime application.

* Tracker doesn't index everything. I don't want Tracker to index a lot of directories because file changes often or files will pollute results of things I actually care about.  Like if I download a random 'git' repository to compile some software I don't want that to get mixed up in my results because I don't ever really want to look at the contents of those source files.  Another example of a directory I don't want to search through would be my ~/Downloads or any temporary directory I create in my home directory.

HOWEVER I do want to be able to find any file in those directories using Nautilus. For example if I need to edit a Makefile to get something to compile finding that easily and opening it up in Gedit would be great... but having Tracker index everything in that directory would be a terrible thing to happen.

So on and so forth.

Thank you and good luck.

(In reply to comment #26)

> I’ve endured this for over a week now, at home and at work, and it’s really
> painful[0]. Can you roll back the type-ahead changes for now?

Tobias, when you are using unstable development releases at work, I don't think you get to demand reversals after 'over a week'.

Seriously, guys, this change is *awful*. "Find" function have a toolbar button and a hotkey already. Why killing another essential feature to add even more undeserved attention to it? Adding insult to injury, this "find" thing doesn't work on remote file systems and removable media outright.

A good cool, fast, contextual Search would be a great thing, and I'm all for that.  But searching is completely orthognal to navigation, and something I want much, much less frequently than a local navigate to file.  So keeping navigation as it is, while adding quick access to search is, I think, a good idea.  (Correspondingly, I think that breaking navigation for any reason is a bad idea.)

(In reply to comment #29)
> (In reply to comment #26)
> 
> > I’ve endured this for over a week now, at home and at work, and it’s really
> > painful[0]. Can you roll back the type-ahead changes for now?
> 
> Tobias, when you are using unstable development releases at work, I don't think
> you get to demand reversals after 'over a week'.

I don’t demand anything. I’d like Cosimo to realize that removing type-ahead is a bad idea, and that as a maintainer he should serve as a gatekeeper and arbitrate.

(In reply to comment #30)
> this "find" thing doesn't work on remote file systems and removable 
> media outright.

What are the IDs of the bug reports that you filed (in a neutral tone) about it?

(In reply to comment #32)

> I don’t demand anything. I’d like Cosimo to realize that removing type-ahead is
> a bad idea, and that as a maintainer he should serve as a gatekeeper and
> arbitrate.

I don't know what makes you feel entitled to be so patronizing with me; please don't.
I already expressed my opinion on this - I don't see type-ahead find coming back. If you feel like doing something helpful and making search work better for your use case, feel free to pick one of the items on the roadmap [1]; there's still plenty of work to do.

[1] https://live.gnome.org/Nautilus/Roadmap/3.6

Okay, Cosimo. You’re welcome to question my intentions, but I sense a bit of a contradiction looking at this:

https://bugzilla.gnome.org/show_bug.cgi?id=676899#c2

This is exactly what I’m asking for. But you seem to have changed your stance on that despite what has been pointed out above. Please explain.

If you remove type-ahead find from the main view, just make sure we still have a place to browse directories like we did for the last 10 years. Tobias' example with hierarchically organized music folders is very appropriate.

Imagine that you want to go to ~/pictures/funny/cats. With "type ahead" you can just type pi->Enter->fu->Enter->ca->Enter. If you type "cats" with the new search feature, it will display a random list of files containing "cats" in their name. You may have files named "cats" everywhere.

A workaround would be to use the location bar. We could just focus the location bar (ctrl+L), then type pi->Enter->fu->Enter->ca->Enter. However this would require:
 * do not unfocus/close the location bar when we hit enter.
 * maybe enable filename autocompletion in the location bar (currently it only autocompletes directory names)

This would be a rather complete replacement for the type-ahead find feature. Only

Other points:
 * Tracker IS slow. Make sure this is fixed before releasing such a big change. (I never enable/install it on my machines because of this). See the screencast at https://bugzilla.gnome.org/attachment.cgi?id=219062 which clearly shows this point.

Anyway, I think this change comes from a good intention, and will provide great benefits; but do not release this in the current state, as it breaks functionality without providing a replacement, and there is still much work to do on tracker. Maybe postpone this to a later (3.8?) release

Indexing directories is _never_ going to be suitable for everything. It's not something you can depend on for listing or browsing files in a file system.

It doesn't matter how fast Tracker runs or how slick the search user interface is. The quick directory browsing functionality that 'type ahead' provided is simply CANNOT be replicated by anything that tracker can provide. 

Because:

1. you cannot index remote file systems without significant deleterious effects on those file systems. Nautilus not only needs to be usable with the gfs-vfs stuff, but also with file systems outside of it's control such as nfs mounts, smb2 mounts, AFS, and who knows what else. 

2. People expect that a file system manager is realtime application. When browsing file systems you need to be able to browse files realtime as they are updated by not only the current application, but by others. If tracker is busy somewhere else indexing files then it's results will not be useful for the current session.

3. Many directories should not be indexed. Directories that change often won't yeild useful results. Temp directories shouldn't have their results added to the search stuff. 


So if you want a consistent use interface for browsing and manipulating files then you cannot depend on tracker or any other back ground indexing system for any major UI features.

(In reply to comment #36)
> Other points:
>  * Tracker IS slow. Make sure this is fixed before releasing such a big change.
> (I never enable/install it on my machines because of this). See the screencast
> at https://bugzilla.gnome.org/attachment.cgi?id=219062 which clearly shows this
> point.

No, it doesn’t. 

That was merely a »no tracker, synch« vs. »no tracker plus mlocate, asynch« demo that I posted to show how the mlocate db could speed some things up.

Tracker/Search is not the expected behavior of Nautilus. It ruined usablility of the software as a file manager. When i type something in File Manager, i expect it to match something in the current directory. No more than this, or else it not file manager. (and then what Nautilus is ?) 

I would like to appreciate in developers efforts who bring growth to Nautilus. New Nautilus is better than old one in many ways. But Tracker/Search should not replace the default behavior of type-in. It may made sense, however, to replace this with something like CTRL+F to trigger the search. Or provide a seperate search box the way Firefox did.

That sounds more reasonable, IMO. 

Just copy the search/browse mechanisms and key presses used by Firefox and/or Chrome browser. These are proven to be friendly and powerful. They do not yield unexpected or conflicting functionality. What is more is that they will be familiar and feel 'natural' the majority of users. With the familiarity that users have with these major web browsers, and the integrated search/find mechanisms they provide, then it will seem very 'natural' to those users.

(In reply to comment #39)
> When i type something in File Manager, i expect it to match something 
> in the current directory.

Isn't that covered now by (fixed) bug 680163?

(In reply to comment #41)
> (In reply to comment #39)
> > When i type something in File Manager, i expect it to match something 
> > in the current directory.
> 
> Isn't that covered now by (fixed) bug 680163?

I mean matching the way type-ahead ever did. Not triggering search like the current behavior. Searching should never replace type-ahead.

As written before, type-ahead find will likely NOT come back.

As argued before, your former users will likely NOT come back.

And the brave souls who still use GNOME will probably leave soon, if you continue like this.

Please learn how the most popular similar computer software works (hint: Windows Explorer and Firefox), and use the same paradigms that everyone else uses, and which have been proved to be effective: type-ahead find and a search box in the upper right of the window...

Go to a forum if you want to discuss sizes of userbases or other random generic stuff that has nothing *specific* to do with a certain bug report that you comment on (and that you only just created a Bugzilla account for).
Please learn that Bugzilla is not a place for general remarks.

Please learn to read comments.

It contains an excellent piece of advice: both Windows Explorer and Firefox have type-ahead find and added search not by removing it, but by adding a new search box in the top right of the UI.

The fact that Windows Explorer has at least 80-90% of desktop market share, while Nautilus has very optimistically 1-5% is pretty important: it means most potential new users are familiar with the behavior of Windows Explorer (and also, it means that Windows Explorer is at least good enough for almost everyone), to say nothing of the fact that Firefox and all other browsers (albeit with a combo url+search box) do the same.

Furthermore, that approach has quite a few obvious dramatic advantages:
1. A search box is far more discoverable than having typing magically invoke global search (especially on the touch devices you like so much)
2. It doesn't break the expectations of the vast majority of users, who are used to either current Nautilus versions or Windows Explorer, both having type-ahead find
3. It doesn't remove the useful type-ahead find feature
4. It doesn't cause users that think type-ahead find is essential to switch to another application

But maybe GNOME just doesn't have user satisfaction, market share, good design or ease of use as goals, in which case I apologize for wasting time discussing on how to best achieve those.

(In reply to comment #46)
> But maybe GNOME just doesn't have user satisfaction, market share, good design
> or ease of use as goals, in which case I apologize for wasting time discussing
> on how to best achieve those.

Yeah, market share is not discussed in a bug report about a file manager implementation detail. Please understand comment 45 or your account might be deactivated. But you probably knew that already anyway.

I simply mentioned the fact that Windows Explorer has 80-90% market share, and not really discussed it, since there's no need to as it is a pretty obvious fact.

That fact, combined with the fact that Windows Explorer is a file manager like Nautilus and resolves the issue of this bug in a certain way (it has type ahead find + search box) seems to me pretty essential when evaluating this bug.

In general, unless there's some advantage in not doing so, you want your software to behave the same as the market leader, since that means that the majority of new users, who are familiar with the market leader (by definition), will be able to immediately use your software and be productive and happy with it.

In addition when the market leader behavior is also the behavior of the current version of your software, that's an even stronger indication.

Since a search box is extremely effective for doing search, and given all the other good arguments put forward by others, I don't see any advantage in deviating from Windows Explorer's behavior (and actually, I see a disadvantage even if you ignore the familiarity/convention issue), so I think you should not do so and should revert this change, leave alone type ahead find and implement a search box.

(In reply to comment #43)
> type-ahead find will likely NOT come back.

By having the type-ahead functionality no longer working, the resultant state of Nautilus is consistent with having a regression. I'm a long time user of Nautilus and rely on the type-ahead functionality.

It would be preferable to add the new search behaviour via control-f and/or a new find button, and leave the existing type-ahead functionality as is.

Removing the old behaviour is not a problem if the replacing feature allows achieving the same workflow. The essential part of this bug report if that the way the new feature is currently implemented breaks keyboard navigation. This can be solved e.g. by listing the relevant files and directories in current directory above the other search results and instantaneously displayed, even if the search takes a bit to provide results (and maybe have them visually separated).

Please stop complaining that the old way was the best and that the designers and maintainer should not do their job. Let's rather see how we can improve the situation and help them in their work.

Alexandre, why did you change the title of my bug report? 

I disagree that it’s merely keyboard navigation that got broken. There are other issues enumerated above and in other places.

Change it back please.

You have decontextualized and disowned all the concerns voiced by repurposing this bug to the one gripe you have. File your own bug about that.

(In reply to comment #51)
> I disagree that it’s merely keyboard navigation that got broken. There are
> other issues enumerated above and in other places.

Could you please break it down in order to identify specific, well-defined issues so that developers can work on them and fix them for 3.6?

From the roadmap...

Done:
Bug 680163
Bug 681379
To Do:
Bug 325146
Bug 663242

If there are remaining *specific* issues please file them separately. As it is there is no way to evaluate this bug or to decide if it is fixed or not.

I’ve identified my gripes above. Elsewhere people added that for example they want to be able to jump back and forth in alphabetical lists while they keep viewing them in context. Other things I read is that this breaks consistency with standard GTK behaviour in treeviews.

But before Jon and Cosimo get Nautilus out of the current limbo and implement what they have in mind there’s no point disputing because we still have no feeling for what the latencies will be and other contingencies.

Unfortunately the Gnome git PPA has stopped pushing Nautilus out now because they are unsure how to deal with the current state.

Alexandre has just no business in messing with this bug report unilaterally.

> Who	                        When	 What	Removed	Added
> william.jon.mccann	2012-08-13 16:59:25 UTC	 Status	UNCONFIRMED	RESOLVED

Great. I expected that. Good luck then.

(In reply to comment #35)
> Okay, Cosimo. You’re welcome to question my intentions, but I sense a bit of a
> contradiction looking at this:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=676899#c2
> 
> This is exactly what I’m asking for. But you seem to have changed your stance
> on that despite what has been pointed out above. Please explain.

What I said in that comment was:

"I think until we have a better search function we could keep these on in the
main views (the icon view has it too) since it can be quite handy to quickly
select files."

We now have such a better search function - I don't really see the contradiction (except that I might draw the line of what "better" means in a different place than you do).

> We now have such a better search function - I don't really see the
> contradiction (except that I might draw the line of what "better" means in a
> different place than you do).

That’s right. My opinion is that the search function is not good enough to replace type-ahead find functionality, regardless of what delusions you have.

But filing bugs like this in Gnome is pointless because you people push whatever strikes your fancy regardless of their relative merit.

So, I’ll not do that anymore. Good luck.

(In reply to comment #55)
> I’ve identified my gripes above. Elsewhere people added that for example they
> want to be able to jump back and forth in alphabetical lists while they keep
> viewing them in context. Other things I read is that this breaks consistency
> with standard GTK behaviour in treeviews.

I just re-read the whole bug report, and I can't really find anything that hasn't been fixed already in the meanwhile, or is not filed as another bug report already. To be fair, I think some of the points you raised in this report are perfectly valid concerns, but repeating "I want the old behavior back" is not going to make things magically work, or better.
If I failed to find other specific points of concern which are not addressed in other bug reports, please make a last effort and point me to those.

> But before Jon and Cosimo get Nautilus out of the current limbo and implement
> what they have in mind there’s no point disputing because we still have no
> feeling for what the latencies will be and other contingencies.
>
> Unfortunately the Gnome git PPA has stopped pushing Nautilus out now because
> they are unsure how to deal with the current state.

That sounds to me very much like a deliberate choice of Ubuntu rather than a technical difficulty; pushing out updates to people ensures bugs get identified and fixed, and feedback is propagated to the developers where it belongs. We've been fixing bugs and regressions and optimizing the behavior almost daily since this work started, and I don't see how things are going to get better by stopping this.

(In reply to comment #58)

> That’s right. My opinion is that the search function is not good enough to
> replace type-ahead find functionality, regardless of what delusions you have.
> 
> But filing bugs like this in Gnome is pointless because you people push
> whatever strikes your fancy regardless of their relative merit.
> 
> So, I’ll not do that anymore. Good luck.

What I find pointless is making these absolute claims with the confrontational "I will always know better" attitude you've been having throughout the whole conversation.

Regardless, I hope we'll be able to buy you back on merit. Despite what you might think, developers care about the software they write and their users.

> If I failed to find other specific points of concern which are not addressed in
other bug reports, please make a last effort and point me to those.

What about the near-type-ahead-find replacement I suggested in comment 36 ? (moving type-ahead find to the location bar only, implementing the 2 suggested changes). I don't think there is a bug report about this. What are your opinions?

Thanks

Well, this is probably going to be regression that marks the end of the current GNOME maintainers.

It seems that dissatisfaction has reached the critical mass that will probably shortly lead to Ubuntu forking everything and all other distributions following.

Hopefully, Red Hat or the GNOME Foundation will eventually realize this as soon as possible and finally fix the problem by removing the saboteurs that they mistakenly entrusted with GNOME.

If you have voting rights on the GNOME Foundation, please vote for anyone who is going to remove the commit rights of Cecchi, McCann and all the other vandals that are currently roaming free and devastating everything they touch.

If you are their manager at Red Hat, fire them.

alright. This is really starting to piss me off now.

Mr 'tnhrc@safetymail.info' and all other jack-offs in this thread:

This is NOT your personal blog. This is NOT a mailing list for discussing your personal opinions on the software or it's developers. 

What you are doing is destroying any discussion or progress that real adults are trying to accomplish here. So go and take your bullshit opinions, anonymous email accounts, and over inflated and entirely undeserving sense of entitlement and go and shove it were the sun doesn't shine. 

The developers that maintain the bugzilla have repeatedly and politely tried to steer the discussion back on track on the actual bug.

But you know what? You and everybody else just completely and utterly ignores it and continue to act in a disrespectful and antisocial manner. And if in your personal life you don't quite understand why people steer away from you and you don't have many friends or whatever... this is probably indicative of how you behave normally. If then I am only doing you a favor by pointing this out. 

Please take your prounouncements and unrelenting posing and restrict yourself to proper forms and your own blog somewhere were nobody will be bothered by it and will forever be associated with you, personally.

Please.


What I want, and what most people want is simple:

We want the ability to quickly find and locate in a directory, while in _context_, the filenames that start with a particular letter or string sequence. This should be done in a quick manner and without resorting to stored data that will be context sensitive and inconsistent across any directory or file system we are likely to encounter while using a Gnome desktop.

'Write ahead' is just one of many methods that can be used to accomplish this. The developers have stated repeatedly that they do not think that such functionality is appropriate for their software.

This is _FINE_. For people that do really specifically want and need this specific feature a Nautilus plugin can accomplish it. This is why plugin system exists. 

For everybody else and the Gnome developers...

As stated above there are numerous ways to accomplish very similar functionality that other software uses.

For example:

In 'vim' and most other command line software that have pager-like functionality it is common that hitting '/' will bring up a 'in-context find' function. This would be appropriate for Nautilus to adopt because it will remain consistent with other software and will be something that long time Linux users will be familar and comfortable with.

In browsers and most other software dealing with 'pager like functionality' the key combo 'ctrl-f' is commonly used. This exists in most other GUI software in existence. Microsoft products, other Gnome products, almost every GUI web browser, etc etc. 

Since ctrl-f is already used in Nautilus then the '/' button would probably be the most appropriate for a 'in-context filename string match' type thingy.

>'/' will bring up a 'in-context find'
> function. This would be appropriate for Nautilus to adopt because it will
> remain consistent with other software and will be something that long time
> Linux users will be familar and comfortable with.

I agree with this and the general method, that is to say "hiding" the type-ahead search mode behing a key shortcut( being it the Ctrl+L location bar - comment 36 - or / or Ctrl+f which are well known).

> Since ctrl-f is already used in Nautilus 
If entering any character directly triggers tracker search, then wouldn't Ctrl+F be redundant/obsolete/deprecated? If that is the case, ctrl+F could be used for type-ahead. But maybe it is better to keep the "Search" button and Ctrl+F as they are, and provide another shortcut for this.

This will deserve another bug report at some point, but we can continue discussing this here for now if you like.

(In reply to comment #64)

> This will deserve another bug report at some point, but we can continue
> discussing this here for now if you like.

Actually, there is one such bug already: bug 681871

If I understand it correctly, that goes much in the same direction as what is proposed in the 2 previous comments.

I've checked latest version from Ubuntu 12.10 beta repositories and it works now well. 

There's a button to do search and look & find inside directory works perfectly.

That's the right way to do it! Well done! 
Thank you again.

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

Hello,

I don't know if I should write here or open a new bug, I think this is the place.

It seems lot of people (including me) doesn't like at all the new search feature, I'll not rewrite the arguments again, it's also clear that you don't want to give up on this feature.

Well, I think there is an option that can satisfy both views, why not add a new configuration (as with the close, minimize buttons) to allow us change the type-ahead behavior? I suppose it can be easily done and it can allow users to use Nautilus as preferred, leaving the decision to them instead of you carrying with it. At the end, programs are for the users.

How do you feel about?

(In reply to comment #68)
> How do you feel about?

It seems that in general people who disagree are more vocal than all those many silent users happy with it, and I feel like we don't want to add another option.

That's what politicians say about a protest. There are always more people silent than complaining, you can't base your decision on that.
You have to admit people is complaining a lot about this feature, and if you don't want to change your mind, at least give an option to change it. It can only improve user experience.
Whoever wanting to change can do it and doesn't need to change to previous unsupported versions or to other program. The "happy" users will not see the difference.
What's the problem with that? At least consider it.

Hi — apologies if this is not the right bug for this, I haven't seen it mentioned in the other type-ahead bugs but I think it's a point worth raising.

Type-ahead-recursive search can match files unexpectedly, especially as it starts matching on stems as soon as you type. This can result in you inadvertently showing files (including, depending on other factors, their content: thumbnails, text excerpts, etc.) on your display. If this is unexpected behaviour (say, you're used to type-ahead-find as implemented everywhere else and GNOME < 3.6), then you may trigger it at times when you have people watching your screen. This can mean disclosing sensitive or personal information by accident.

For example, if I were looking for a work-related document in my ~/Work folder to show a colleague, there is a risk I may inadvertently show a filename or file excerpt relating to something confidential, such as job description, pay information, classified stuff, etc. which may not be appropriate for my audience.

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

From my duplicate:

I wish to register my dissatisfaction with the current design, which is surprising, confusing, and not what any other file manager does. GNOME already has a filesystem search built into Dash and a magnifying glass search button on Nautilus's toolbar that can easily accommodate this functionality, so I'm not sure why overloading the standard file selection type-ahead behavior is still necessary. Given tracker and how well GNOME's full text search works from the Dash, it may be time to revisit this.

+1 to what Nate Graham said.

I like the full text search (a lot), just like I like type-ahead. For me, those are different features that enable different things (searching vs. navigating). (My) usability problems:
- Not displaying context (files and folder below and above)
- Popping up of additional search results leads me to not hitting the correct file or folder on the first attempt
- To an extent, I can fix my issues by disabling the subfolder search. On the other hand, sometimes I want to search in the subfolders. (Analogous problem the full-text-search option.)

Big fan of GNOME, keep up the great work!

+1

I prefer type-ahead find when browsing through files and folders. Replacing it with search is, in my opinion, a mistake.

Avoid "me too" and "+1" please, they just add noise. Only comment if adding new information not present in the previous 75 comments.

I agree with Thomas Wolf and davidpfander. In my view type-ahead and search are two different features. And this is a decision, scaring away many keyboard power-users.

type-ahead as it was, doesn't need to be the default. I understand that you want to create something fancy new and easy by merging the search in this way and making everything easy for newbies who work with the mouse 90% of the time anyways. But IMO there should be at least a config option somewhere, to go back to the old behavior somehow.

At least for me, this change absolutely kills my productivity.

Guys, there's no point in commenting here. It's design decision. The GNOME devs know that it's controversial and alienates certain people. We're not the target audience. If GNOME's design decisions aren't working for you, a more productive vehicle for your frustrations is to find another platform, not yell at the moon.

Another reminder of comment #77, please only add information that was not said previously, specifically avoid 'me too', 'I agree too', '+1' comments, they just add noise to the already noisy comment section.

There is once again a working patch available to restore the typeahead behaviour.

It is here:

https://aur.archlinux.org/cgit/aur.git/tree/nautilus-restore-typeahead.patch?h=nautilus-typeahead

And a version of nautilus built with it can be installed in arch via the AUR.

For those on Ubuntu 18.04 there is a PPA:

https://launchpad.net/~lubomir-brindza/+archive/ubuntu/nautilus-typeahead

+1's and me toos might not help much here, but the good thing about open source is that you can vote with your feet. If the developers won't include a change but the community wants it enough to maintain their own patch, then we don't need their agreement. So use the patched version, help maintain it, and report the bug to your distros instead, asking them to include the patch.

Just some comments in case someone needs to be aware:
- The patch seems to be a simple port of the Ubuntu patch, which was buggy here and there.
- It makes some assumptions that are not true (e.g. type of views) and will lead to crashes depending on your Nautilus set up.
- That code is truly not easy to understand or maintain, so I have my reservations that the code could be maintained properly or updates could be slow.
- It won't work in gtk4.

Carlos, that's just FUD.

I've yet to encounter bugs with this patch, whereas without the patch search doesn't function as keyboard navigation for me because of this bug:

https://bugs.launchpad.net/bugs/1767027

And because without 'limit search to current folder' enabled it's not performant. So let he who is without bugs cast the first stone.

It'll work on gtk4 if people port it to gtk4.

Feel free to ignore my comment if you don't agree, of course.