restore type-ahead find

[Adam Dingle]

GNOME removed type-ahead find in Nautilus 3.6, not without controversy:

https://mail.gnome.org/archives/nautilus-list/2012-August/msg00002.html

Now when you type in a Nautilus window, Nautilus immediately performs a search in the current directory and all its subdirectories. I personally find this annoying. If I want to search, I'll click the search icon. Often I'm looking at a long directory listing and simply want to jump to a certain point in it, and type-ahead find works great for that.

Would Ubuntu consider patching type-ahead find back in?

[Sebastien Bacher (seb128)]

Thanks Adam, it's something that annoys quite some people indeed. We are not sure what to do at the moment, nautilus 3.6 is an user regression compared to 3.4 on several fronts.

We are discussing adding back nautilus 3.4 as an option (and maybe make it the default in Ubuntu) but it's an unmaintained software upstream and it doesn't seem to be a good idea to suggest it to users if we are not going to have the resources to fix issues with it...

[Adam Dingle (adam-yorba)]

Yeah. My vote is to stay with the current Nautilus (3.6 in Raring) since it is maintained upstream, but to use patches or plugins to fix the most important regressions.

[Alfredo Matos (alfmatos)]

I would say that this is a long way from Low Importance. As a desktop user I hit this bug dozens of times per day, and over time this is incredibly frustrating to the point of having installed several alternatives, and even considering dropping Unity/Gnome in favor of KDE (or something sane).

[Alfredo Matos (alfmatos)]

Best workaround so far is to install nautilus 3.4 in 13.04:
http://www.webupd8.org/2013/04/get-nautilus-34-features-back-in-ubuntu.html

[Adam Dingle (adam-yorba)]

I've also filed this upstream at

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

[Adam Dingle (adam-yorba)]

One more point. When the Nautilus designers replaced type-ahead find with search-as-you-type, their intention was that searching as you type would be really fast because Nautilus would use Tracker to search. See, for example, the comment https://bugzilla.gnome.org/show_bug.cgi?id=680118#c4 : "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."

Because Ubuntu does not use Tracker, searching as you type in Nautilus is especially painful on Ubuntu, and so the removal of type-ahead find affects Ubuntu users especially acutely.

So in Ubuntu we could enable Tracker, which would alleviate the problem somewhat, and/or patch type-ahead find back in. I lean toward the patch: it's probably really easy. But I agree with Alfredo that finding some solution to this should have more than a Low importance.

[Benjamin Flesch (bflesch)]

Adam Dingle: Thanks for clarifying that this issue has not been intended by the nautilus developers.

Anyway, this bug affects me a lot and I cannot believe that of all people working at/for Ubuntu, nobody ran into this issue. It is very striking and totally kills directory navigation as I am used to.

[Marco Lackovic (marco-lackovic)]

I also find the removal of type-ahead very frustrating. I think an option to re-enable it should be available.

In my opinion the previous behavior was more intuitive: if I wanted to search fo something I would have used the search function at hand. Before it was possible to discern the two things, (1) go to the file/folder in the current folder, (2) search for a file/folder in the current folders and subfolders. Now only option (2) is possible.

As a workaround, I followed the following suggestion and installed Nemo:
http://askubuntu.com/questions/285793/how-do-i-disable-recursive-search-in-nautilus-3-6

[Justin Force (justin-force)]

The new behavior is INFURIATING. And the search functionality is terrible. Even if it were fast (and it's terribly slow on my Core i7 and Intel SSD), it's stupid. I'm a software developer. When I type 'lib', I want to jump to the lib directory that I'm looking at--not find every directory and file with lib in it recursively. That's insane! And there's a well-established UX for this already: indicate that you want to perform a search by pressing Ctrl-F, F3, or whatever.

This change has made it virtually impossible to navigate Nautilus without a mouse, and so Nautilus is now completely useless to me. HUGE step backward.

I realize that GNOME is doing weird things with Nautilus 3.6, and that the version shipping with Ubuntu is a best effort by Canonical, the Ubuntu community, and friends to maintain sanity. I don't mean to criticize the folks who are doing the best they can. I just want adequately register my frustration here. My Ubuntu desktop experience is seriously hampered as Nautilus is completely useless to me now. It's much more efficient to do all file operations in a shell if I can't type-ahead find.

And I don't think this is an issue of, "Well, I guess it's time to learn new UI." I'm not averse to drastic changes to the UI if they're improvements. This isn't a matter of Old Dog v. New Trick. This is a very, very bad UI decision. It makes the software less useful.

Quick side rant: the GNOME team have been stripping out features and removing useful functionality for years. I understand the idea of boiling down a tool to its most essential parts, the benefits that that has for maintainability, and the elegance of a focused UI. But come on. It's easy to cross the line and break things that people rely on, and that seems to have been GNOME's modus operandi for at least the past 6 years.

[Abraxas (cjay-martin)]

I also agree on this. I used the lookahead as my primary navigation through complex filesystems. I have so many like-named subdirectories that this new feature is dropping my efficiency pretty badly. I was hoping to avoid using any of the cinnamon forks until/unless they became officially embraced by Ubuntu (just for compatibility reasons), but I'm a little stuck.

No rant here, just the facts, ma'am.

[Salvation (jjmatt)]

Just wanted to +1 what everyone else said. One more vote for a type-ahead search function.

[M4he (mahe)]

Can someone put together a patch, which incorporates the type-ahead search from Nautilus 3.4 into 3.6 ?

[Marco Lackovic (marco-lackovic)]

I switched to Kubuntu, now happily using Dolphin in place of Nautilus/File.

[Florian (florian-phpws)]

I +1 this. I've recently upgraded to 13.04 with nautilus 3.6 and this is the single most annoying thing at all. I quite like how most things are back to basics, but this is the complete opposite. Unless I want to make around for hours with the mouse and clinched eyes, this makes nautilus about as useful to me as a car with built in satnav that can only turn left. I would love to see a patch for this. As others mention, if I wanted to do this kind of search I would, well, search (Ctrl+F etc.).

[James (ubuntu-soundunreason)]

I concur. At least make this optional/switchable. It is a feature I do not wish to use. I like typing a few letters and jumping to a section in the list.

[Tomasz Kucharski (qhrrrr)]

Just wanted to agree with above, and show by posting that there are more frustrated users. This "feature" beats famous Win8 Start button. IMO it's worst "feature" ever designed, I'd love to see how developers of this software uses their file mangers. I can't understand why there is no way for users to configure this behavior. Even advanced users have no option to reconfigure. Why????

[M4he (mahe)]

Best workaround currently available: http://www.webupd8.org/2013/04/get-nautilus-34-features-back-in-ubuntu.html

[Christian González (droetker)]

Installing an old nautilus is no option here. This is a really annoying, broken feature and should be reverted to the old behaviour. Starting to type lets you loose your overview of where you are in the file system. If I want to search, I press Ctrl+F. Then this search should be available.

Please remove this "feature" again.

[Sebastien Bacher (seb128)]

Thanks for the interest/comments there, Ubuntu doesn't have a nautilus hacker though and that chance is coming from upstream, it would be better discussed on the upstream bug tracker/mailing list than on launchpad ... while we agree that the current situation is suboptimal not sure that's a problem that can easily by fixed by Ubuntu

[M4he (mahe)]

I strongly recommend Canonical to maintain their own version (fork) of 3.4 (maybe with the SolusOS patch). I think Nautilus 3.4 is a mature software already.

[Adam Dingle (adam-yorba)]

Sebastien, thanks for your comment - it's nice to know that someone at Ubuntu is paying attention to this thread.

I don't think forking an old version of Nautilus is practical. The problem is that it would be a ton of work to keep such a fork compatible with new versions of GTK, GLib and other libraries. Instead I think the current version of Nautilus (3.8 in Saucy) should be patched to fix this.

Removing type-ahead find has been controversial upstream (i.e. at GNOME) - see, for example, the discussions at

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

Nevertheless I think it's very unlikely that the GNOME developers will fix this for 3.10, or possibly ever. Even if they were to fix this in, say, Nautilus 3.12 next spring, that version won't appear in Ubuntu until late 2014 (since Ubuntu lags GNOME by a release cycle). So if this going to be fixed in Ubuntu in the near future, I think Ubuntu will need to take responsibility for doing that. You may not like that - sure, in an ideal world this would be discussed rationally and fixed upstream - but this is how it is.

You wrote "not sure that's a problem that can easily by fixed by Ubuntu". I guess that depends on what you mean by "easily". I'm quite confident that a competent hacker could come up with a patch to the current Nautilus that restores type-ahead find in, say, 2-3 weeks. It might even be easier. I'd start by attempting to git revert the commit where this breakage was introduced:

https://git.gnome.org/browse/nautilus/commit/?id=469eb89117e199a450aec3411183ed2e9f10f893

That will yield merge conflicts, which must be studied and resolved in some nice way. This might not be solvable in a day, but I'd be very surprised if this took more than a month of work.

To those of us on the outside, it's baffling that Ubuntu would not want to invest that amount of effort to solve this, since this is a highly visible core program on the Ubuntu desktop and it seems pretty evident that the majority of users are harmed by this. Has someone at Ubuntu already spent several weeks working on this and concluded it was too difficult? Or does Ubuntu not feel it would be worth that amount of effort?

[Sebastien Bacher (seb128)]

Hey Adam, thanks for your comment

> Has someone at Ubuntu already spent several weeks working on this and concluded it was too difficult? Or does Ubuntu not feel it would be worth that amount of effort?

Well, neither, the current desktop team has around 10 people to maintain the desktop ... that includes the complete GNOME stack, xorg, firefox, libreoffice, etc.

In practice that's quite a low amonth of manpower compared to the number of packages to maintain, blocking time from an hacker for more than half a day is difficult for us... there is no way at the moment to spare someone for a week to resolve nautilus issues, we just have to sneak fixes in between higher priority work

Oh, for the record we do agree that this bug is annoying and would like to fix, we just need to deal with what we have

[Adam Dingle (adam-yorba)]

Sebastien, thanks for your reply. Given your staffing level I can see why this is not as easy as it might seem.

According to this page Canonical has over 500 employees:

http://www.canonical.com/about-canonical

If only 10 of them are assigned to desktop maintenance, I would say that team is seriously understaffed. But that's probably a discussion for another forum, not this bug thread. :)

[Sebastien Bacher (seb128)]

> If only 10 of them are assigned to desktop maintenance, I would say that team is seriously understaffed. But that's probably a discussion for another forum, not this bug thread. :)

Right ... note that we have more "desktop" people than that, but most of them are working on Unity and Ubuntu Touch ... which limits our capacity for issues on the "traditionnal desktop". But as you said, that's a discussion getting out of topic for this bug ;-)

[Moritz Oberhauser (zomtir)]

Unfortunately it seems that it's less a question of sense but stubbornness. Immediately after the changes were merged, they came up with the "Find in view is broken issue":
https://bugzilla.gnome.org/show_bug.cgi?id=679900

natermer left a long and very biased comment, indicating that Gnome won't return to the type ahead functionality. Not sure how deep he's involved into developement:
https://bugzilla.gnome.org/show_bug.cgi?id=680118#c63

It might be worth a try to directly contact the responsible devs and have a polite discussion wether this bug was marked "invalid" on a technical and comprehensible reason, considering design and consistency being a bad tradeoff for usability and freedom of choice.

If Gnome then still persist on the Apple pathway, how are the chances of getting a type ahead plugin working?

[Andrew Simpson (adpsimpson-gmail)]

To add my voice to this bug, I installed 13.04 today, on my work computer (previously Windows 7 only), to enable me to use a variety of bash scripts to process a large number of files on an external ext3 drive. At home I have 12.10 installed.

The files are images, several thousand per folder, stored in dated folders (such as 11-04-23-country_location). Now I know, for example, that I was in Belgium in May 2005, so I type '05-05' and a folder NEAR the one I want was previously highlighted, allowing me to quickly and easily find the correct folder. A related task is to go to the next, and previous, folders. Both of these uses are broken with the new search set-up.

The Gnome team's total brick-walling of the furious users should give pause for thought. I simply cannot believe they have shot themselves in the foot so categorically as to make the staple piece of software, that underpins their entire user interface, so crippled.

This is a far more serious usability issue than anything thrown up with the migration to Unity. I would rate it, probably, as the highest, most disruptive user interface bug I have ever come across in Ubuntu (and I've been with you since Warty).

The workaround linked by M4he above is good news, but the idea of having to install a patch to get basic file-browser functionality is insane. Even more insane than firing up Mac OSX and being faced with the abomination that is Finder.

Sebastian, it's great news that Ubuntu are listening, and seeing this as an issue, and I hope a proper solution is forthcoming. At what point does a frankly bizarre upstream user interface decision like this become priority #1 at Canonical? When it begins to compromise the very good work being done with Unity? When does it become worth moving a developer from Unity onto an issue like this?

[Adam Dingle (adam-yorba)]

Well stated, Andrew. I myself have used Ubuntu since the days of Dapper Drake, and I agree that this is one of the most serious usability problems I've seen in Ubuntu during that entire time.

[firolp (firogm)]

It's really a terrible things that disable type-ahead find. Please,implement a plugin or option to reenable type-ahead find.

[Dr. Amr Osman (dr3mro)]

this patch works with nautilus 3.6 on ubuntu 13.04
this is patch i uploaded it to my ppa:dr3mro/personal
have fun

[Dr. Amr Osman (dr3mro)]

after installing the patched nautilus
dconf-editor
org.gnome.nautilus.preferences

uncheck

enable_recursive_search

restart nautilus
have fun !!

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "enable_disable_recursive_search.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Dr. Amr Osman (dr3mro)]

I have poste bug fix
https://code.launchpad.net/~dr3mro/ubuntu/raring/nautilus/fix-1164016/+merge/177266

[Dr. Amr Osman (dr3mro)]

I have requested another merge
https://code.launchpad.net/~ubuntu-desktop/nautilus/ubuntu/+merge/177385

[Adam Dingle (adam-yorba)]

Dr. Osman, thanks for your patch. A few comments:

1. Of course, this patch does not restore type-ahead find as originally requested in this bug ticket. Instead, it simply disables recursive searching, so that as you type only files in the current directory are returned. Still, this does significantly ease the pain of this upstream change. If Ubuntu can't summon the resources to restore type-ahead find in 13.10, I would recommend landing this patch since it's ultra-simple and does make things less painful. I'd further recommend modifying the patch so that non-recursive search is the default (as it stands, the user must set a GSettings key to disable recursive search, and few users will figure out how to do that). The GSettings key would then let users *enable* recursive search if they really want to. I suspect that few users will.

2. You really should be patching Nautilus 3.8.2, which is the current version of Nautilus in Ubuntu 13.10, where this is most likely to land. (I wouldn't mind seeing this backported to 13.04 either, though.)

3. In the patch, I believe you could simplify this code:

if (g_settings_get_boolean (nautilus_preferences, NAUTILUS_PREFERENCES_ENABLE_RECURSIVE_SEARCH)) {
  g_object_set (simple_provider, "recursive", TRUE, NULL);}
 else
 {
 g_object_set (simple_provider, "recursive", FALSE, NULL);
 }

to:

gboolean recursive = g_settings_get_boolean (nautilus_preferences, NAUTILUS_PREFERENCES_ENABLE_RECURSIVE_SEARCH));
g_object_set(simple_provider, "recursive", recursive, NULL);

Fewer lines are better. :)

[Dr. Amr Osman (dr3mro)]

@adam-yorba
ok did your suggestion
thank you
https://code.launchpad.net/~dr3mro/nautilus/fix-1164016

[Xavier (rxaviers)]

Looking forward to seeing this patch get landed. So, we are able to use Nautilus again. Any updates or plans on when it's gonna happen?

PS: I make Justin's my words. Current regression is INFURIATING.
Go Ubuntu, save us all from this evil.

[carez (carez)]

I switched to nemo file manager and very happy since then.

[Darlan Alves (darlan)]

Looking forward to see this thing fixed too.

It's just insane that a bug that made people install alternative packages just to get rid of a tiny new feature is not considered a ultra-super-high priority on Ubuntu teams.

I'm using Ubuntu for years, and this is the most annoying thing I've ever noticed since Unity was introduced. At first, I found myself cursing Ubuntu for that sudden UI change, but Unity made its way and now I really like it. I don't think the same gonna happen with this damn search thing.

Nautilus browsing is just useless right now! I prefer "Ctrl+Alt+T", "cd to/a/path", and "nautilus .&" instead of touch my mouse or insanely arrow-navigate to do so. I would try to fix it myself if I knew C++ =/

Please, pleease call Mark to dev's room and ask him for a "Nautilus browsing experience". I'm sure it would hate Nautilus as we do right now.

[techzilla (techzilla)]

I also was shocked to see this problem after installing a fresh gnome 13.10, it's slowed my directory scouring ability significantly. Since when is an in application keypress indicative of a full system search???

[Adam Dingle (adam-yorba)]

I just created a bounty for this bug at Bountysource:

https://www.bountysource.com/issues/1072092-restore-type-ahead-find

If enough people chip in, perhaps someone will be motivated to provide a patch that restores type-ahead find as it once was. :)

[Brian Norris (computersforpeace)]

I'm interested in getting this resolved, and I might even be willing to learn the innards of Nautilus just to fix this, but it's unclear what the impact would be even if I did. It seems that upstream made an immovable "design" decision to blaze ahead with the type-to-search misfeature and that nothing users say/do will change that.

So, are you proposing that Ubuntu will maintain a fork (or a forked patch or two) for Nautilus? Is that a reasonable goal? If we develop a simple enough fix, is it likely Ubuntu will carry it separate from upstream GNOME/Nautilus?

[Adam Dingle (adam-yorba)]

To be clear, the term "fork" usually refers to a split in development that no longer merges in changes from the other side, which is not what I'm proposing here. Instead, I'm hoping that if we had a patch to restore type-ahead find, Ubuntu would include and maintain it just as it already maintains various patches for other GNOME programs. The patch might not be trivial, but maybe it wouldn't be that hard to maintain once it's been written once.

Of course, I don't work for Ubuntu, so only they can say whether they would actually accept a patch like this. But in comment #22 above, Sebastien (who works for Canonical) wrote "for the record we do agree that this bug is annoying and would like to fix, we just need to deal with what we have". Given that, I'm hopeful that they would take a patch.

[Sebastien Bacher (seb128)]

Right, we are wanting to include/maintain the patch if somebody writes one. Note that upstream hinted that they might be wanted to take the patch as an option as well...

[Daniel Wyatt (daniel-wyatt)]

Give my branch a try and let me know what you guys think:
bzr branch lp:~daniel-wyatt/nautilus/fix-bug1164016

You'll need to enable it with:
gsettings set org.gnome.nautilus.preferences enable-interactive-search true

The only thing I haven't been able to get working is using the mouse wheel to scroll through matches.

[Adam Dingle (adam-yorba)]

Daniel, could you give us a hint about how to build Nautilus from your branch? I grabbed it with 'bzr branch', then tried

$ sudo apt-get build-dep nautilus
$ ./configure --disable-tracker
$ make

but the build died with

===
nautilus-file-operations.c:69:23: fatal error: zeitgeist.h: No such file or directory
 #include <zeitgeist.h>
                       ^
compilation terminated.
===

I do have libzeitgeist-dev and libzeitgeist-2.0-dev installed. I'm on Ubuntu 14.04.

I also tried

$ debuild -b

but the build failed with this:

cp: cannot stat ‘debian/tmp/usr/share/gtk-doc’: No such file or directory
dh_install: cp -a debian/tmp/usr/share/gtk-doc debian/libnautilus-extension-dev//usr/share/ returned exit code 1
make: *** [binary-install/libnautilus-extension-dev] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1361:
dpkg-buildpackage -rfakeroot -D -us -uc -b failed

[Daniel Wyatt (daniel-wyatt)]

@Adam: I had that issue with the main branch as well, it does not like to build the standard way (so building on non-ubuntu was a pain). ('autoreconf -vfi' will fix that particular error but there are a couple of other issues so just use the below method).

This should work:
dpkg-buildpackage -uc -b

This will generate multiple deb packages you will need to install (sudo dpkg --install ../*.deb).

[Daniel Wyatt (daniel-wyatt)]

All together, something like this should work:
1) bzr branch lp:~daniel-wyatt/nautilus/fix-bug1164016
2) sudo apt-get build-dep nautilus
3) cd fix-bug1164016; dpkg-buildpackage -uc -b
4) sudo dpkg --install ../*.deb (use caution here of course)
5) nautilus -q
6) gsettings set org.gnome.nautilus.preferences enable-interactive-search true
7) nautilus&

After that you should be able to use type-ahead on the desktop and in nautilus windows/tabs.

[Daniel Wyatt (daniel-wyatt)]

@Adam: Missed your gtk-doc issue. My workaround was to add --enable-gtk-doc to DEB_CONFIGURE_EXTRA_FLAGS in debian/rules.
I don't know why that is necessary, things seem a little broken in the ubuntu/saucy/nautilus branch.

[Adam Dingle (adam-yorba)]

@Daniel: Thanks for the additional hints. Actually I found an easier way to build from your branch:

$ dh_autoreconf
$ ./configure --disable-tracker
$ make

That avoids the zeitgeist.h and gtk-doc errors, and allows me to simply 'make install' without having to generate a Debian package.

So great - I was able to try out your changes. This looks quite promising. A few issues:

- It looks like you branched from lp:ubuntu/saucy/nautilus, but I think you should branch from the newer lp:ubuntu/trusty/nautilus:

  https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/nautilus/trusty

- Type a few characters of a filename, then click on a different file. The text box with the characters you typed remains open. Instead, it should vanish, just like in Nautilus 3.4.

- Type a few characters of a filename, then move the Nautilus window. The text box with the characters you typed remains open, and will not move with the window. Instead, it should vanish in this situation, just like in Nautilus 3.4.

- Select the first file in a directory, press the down arrow once, then type the first character of a filename. Notice that a secondary selection rectangle remains around the previously selected file. If you press Escape to exit the search, the secondary selection remains, and if you then press the down arrow Nautilus navigates to the file following it. Instead, as soon as the search begins the secondary selection should vanish, just like in Nautilus 3.4.

- When I select any file or directory in Nautilus, a yellow tooltip-like rectangle appears in the lower right of the window with text descibing my selection, such as

  "scout.png" selected (969.6 kB)

  With your changes, the characters you type appear in a text box on top of this rectangle, which doesn't look great. In Nautilus 3.4, this text box appeared just below the Nautilus window when possible, which looked better.

[OzzyFrank (ubuntu-ozzyfrank)]

The removal of type-ahead find has been driving me nuts since its implementation, so I cast my vote that users be given the option to turn off automatic searching. It staggers me that rather than give us more options to customise our file manager to be as we like it, they're slowly being stripped away. And I have to say, I've been using Ubuntu since 2006, and I'm still waiting for a tool that lets me configure Nautilus without wading through gconf/dconf (though that would likely be next to useless with all the backwards steps Nautilus is taking with every release).

[Adam Dingle (adam-yorba)]

@Daniel: it's been a while since I posted my feedback on your branch so I thought I'd check in. Are you planning to continue working on this? Do you think it will be possible to resolve the issues I mentioned?

[Daniel Wyatt (daniel-wyatt)]

@Adam: Yes, I've been working on it and have improved it based on your feedback. I've spent a lot more time on this than I intended but I want to make sure I do this right since this is actually the main reason I switched away from nautilus.

I rewrote it based on the newest gtktreeview which has a nice interactive search.
Ideally I would like to accomplish all of the following:
1) Support scrolling through search w/mouse wheel
2) Hide search window when mouse clicks somewhere else (_and_ have the other widget handle that mouse press)
3) Maintain keyboard shortcut support while search is open (CTRL+W, XF86XK_HomePage, etc).

As far as I can tell, nautilus 3.4 (nor nemo, nor pcmanfm) do not do all of these things but I really would like to so I'm trying.

Individually they may not be difficult but all together I'm having trouble wrapping my head around it.
I've managed #1 and #2 (somewhat).

[Daniel Wyatt (daniel-wyatt)]

Forgot to add that everyone can see the gtktreeview interactive search by popping up an open file dialog in a gtk3 app (gedit, etc).
You can see that it does #1, #2 (partially, only within the tree view itself, not the places sidebar etc), and not #3 (try CTRL+L for example while the search is open).

[Shoham Peller (shoham-peller)]

@Daniel: That sounds awesome! Really looking forward to it.
Just one question:

> 1) Support scrolling through search w/mouse wheel

What does that mean? There is no search result.. Do you simply mean that the mouse wheel should continue to function while the search box is present?

[Daniel Wyatt (daniel-wyatt)]

@Shoham: I mean that while the interactive search is visible, the mouse scroll wheel will cycle through matches just like up/down arrow keys will and CTRL+G/CTRL+SHIFT+G.

[Shoham Peller (shoham-peller)]

@Daniel: I see.
Are you sure this is the behaviour you want?
In Microsoft's Windows Explorer, the mouse wheel behaves normally when using type-ahead, using it to scroll all through the folder content.
This seems a more suitable way to behave, rather than stopping the cursor at the last file matched when trying to scroll with the mouse wheel.
don't you think?

[Daniel Wyatt (daniel-wyatt)]

@Shoham: I think it's fairly standard. It's the same behavior as nautilus 3.4, nemo, pcmanfm, spacefm, thunar, emelfm2, and marlin.
If anyone else thinks we should do otherwise though, please speak up now rather than later.

[Moritz Oberhauser (zomtir)]

@Daniel: Cycling throught the results w/MouseWheel sounds fine.

If point 2 (Hide search window when mouse clicks somewhere else) is done, one can easily click in the file browser and continue scrolling as usual.

A thing I wanted to add and might be helpul: If Nautilus is opened over a "Select file" button (e.g. upload file in Firefox, open file in certain programs) the recursive search is NOT active but the type ahead functionality. So it is still implemented somehow.

[M4he (mahe)]

@Oberhauser: That isn't part of Nautilus or any other file manager, it's the common GTK file chooser dialog.

[Daniel Wyatt (daniel-wyatt)]

Everyone give this branch a try:
lp:~daniel-wyatt/nautilus/fix-bug1164016_2

It isn't ideal like I wanted it to be but it's pretty good in my experience.

[Adam Dingle (adam-yorba)]

Daniel, thanks for your continued work on this. I tried your branch and this seems like a step forward: most of the issues I mentioned above are fixed. I'm still seeing this issue from before, though:

- Select the first file in a directory, press the down arrow once, then type the first character of a filename. Notice that a secondary selection rectangle remains around the previously selected file. If you press Escape to exit the search, the secondary selection remains, and if you then press the down arrow Nautilus navigates to the file following it. Instead, as soon as the search begins the secondary selection should vanish, just like in Nautilus 3.4.

Actually it seems a bit better than last time around: the first time I type a filename in a given directory view, usually I don't see the secondary selection and the arrow keys behave as expected. But if you repeat the steps above over and over in the same directory view, you'll see that the secondary selection often appears, and arrow keys after Escape often navigate up or down from the secondary selection position, not from the filename you just navigated to. Do you see this too? Is this fixable?

[Daniel Wyatt (daniel-wyatt)]

@Adam: Never had that issue and still can't reproduce it.

Can anyone else reproduce this issue?

[Daniel Wyatt (daniel-wyatt)]

@Adam: I'll try a fresh install and see if I can reproduce it.

[Adam Dingle (adam-yorba)]

@Daniel: Hm - that's interesting that you don't see the issue I mentioned. What version of GTK do you have? I'm on Ubuntu 14.04 with GTK 3.10.6.

[Daniel Wyatt (daniel-wyatt)]

@Adam: Still not able to reproduce. I did the following:

1) Fresh install of 14.04, fully updated, GTK 3.10.6
2) sudo apt-get build-dep nautilus && sudo apt-get install bzr
3) bzr branch lp:~daniel-wyatt/nautilus/fix-bug1164016_2 && cd fix-bug1164016_2
4) dh_autoreconf && dpkg-buildpackage -uc -b
5) sudo dpkg -i ../*.deb
6) nautilus -q
7) gsettings set org.gnome.nautilus.preferences enable-interactive-search true
8) nautilus

If I understand what you're describing, it shouldn't really be possible.
isearch_start (called when you start typing a new search) calls isearch_entry_changed which unselects everything via nautilus_view_set_selection (slot->details->content_view, NULL);
Can you try something similar to the above procedures and see if it's still reproducible?

[Adam Dingle (adam-yorba)]

Daniel, thanks for your heroic efforts to reproduce the issue I described. I just followed your list of steps above with a fresh install of 14.04, fully updated. And I still see the bug!

To be clear, after your steps above:

9) Open a Nautilus window on your home directory.
10) Click the list view icon.
11) With the mouse, click on the Desktop directory (the first item in the list).
12) Type "t". The Templates directory will be selected.
13) Press Escape. Templates will still be selected.
14) Press the down arrow key. Documents (the second item in the list) will now be selected. This is unexpected: Videos should be selected at this time.
15) Type 't' again. Templates will be selected again, but a pale orange rectangle (i.e. the secondary selection) will still be visible around Documents, which is unexpected.
16) Press Escape again. The secondary selection rectangle will still be visible.
17) Press the down arrow again. Now Downloads will be selected, but Videos should be.

What happens if you follow these steps?

[Daniel Wyatt (daniel-wyatt)]

@Adam: Thanks for the clear instructions, got it reproduced now! What a weird bug.

Does this only happen in the list view? Anyways, I'll look into it.

[Adam Dingle (adam-yorba)]

Daniel: Great - I'm glad you see this now. I only ever use the list view, so I haven't even looked to see if it might occur in icon view. :)

[Daniel Wyatt (daniel-wyatt)]

@Adam: Go ahead and pull the new changes from the branch and try again. It works for me now.

[Adam Dingle (adam-yorba)]

Daniel, I tried your latest changes and it seems to work great now. I'd be happy to see this land.

[Adam Dingle (adam-yorba)]

Sebastien, would you consider taking this patch now? Let us know if there's anything more we can do to help.

[Sebastien Bacher (seb128)]

@Adam: we would like to get that feature back for the LTS for sure. I've some post-holiday back but that one is on my todolist, I'm likely going to get to it next week. It might be useful to open a new upstream report with the patch, I think some people said that upstream is open to take back some feature if they are off by default and opt-in through gsettings

[Sebastien Bacher (seb128)]

@Daniel: is there a way you could add your patch as a diff (or a merge request against the packaging vcs, lp:~ubuntu-desktop/nautilus/ubuntu)?

[Doug McMahon (mc3man)]

It has worked well here over a couple of weeks & doesn't seem to add to an existing mem leak in list view.
I do wonder though how many users would find value in a preference's option that is only exposed in gsettings/dconf-editor vs. being available thru nautilus's preferences dialog.

[Daniel Wyatt (daniel-wyatt)]

@Sebastien: I'll open an upstream report with the patch.

Created a merge request for the packaging:
https://code.launchpad.net/~daniel-wyatt/nautilus/ubuntu/+merge/201263

[Osmo Salomaa (otsaloma)]

Thanks Daniel, just to report, this worked fine against 3.8.2 in Debian unstable, I'm using it now and everything seems to work fine. And, please do take the patch upstream, even if it might seem frustrating to argue this case once more.

[Daniel Wyatt (daniel-wyatt)]

@Osmo: Glad to hear that. And I have taken it upstream, forgot to mention:

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

[Daniel Wyatt (daniel-wyatt)]

Upstream killed it so I guess we'll just have to hope it's accepted into Ubuntu for now.

[Laurent Dinclaux (dreadlox)]

Gimme it back !

[Sebastian Bengtsson (5ebastian)]

I navigate nautilus with typeahead, enter and backspace. Used to work wonderfully and was a good example of how the same interface can be usefull usefull for both power user and novice. Now that is completely broken.

This is not a performance problem (tracker/no tracker), it is a qualitative problem. Gnome new word order only works if you have globally unique names for files and directories.

[Vaclav Petras (wenzeslaus)]

Just for reference, the ticket "backspace does not moves to parent directory" is here:

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1124632

[Sebastien Bacher (seb128)]

The patch has been uploaded and is currently in trusty-proposed, a new issue has been reported with that version, bug #1271605 " Cannot close window if type-ahead entry is open"

[Adam Dingle (adam-yorba)]

Wow - it's great to see this land in proposed at last! Many thanks to Daniel, Sebastien, and everyone else who's helped make this happen.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nautilus - 1:3.8.2-0ubuntu11

---------------
nautilus (1:3.8.2-0ubuntu11) trusty; urgency=medium

  * debian/patches/interactive_search.patch:
    - Restore interactive search as an option (lp: #1164016)
 -- Daniel Wyatt <email address hidden> Wed, 22 Jan 2014 15:10:18 +1300

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-settings - 14.04.2

---------------
ubuntu-settings (14.04.2) trusty; urgency=medium

  * Use type ahead find by default in Nautilus (LP: #1164016)
 -- Robert Ancell <email address hidden> Wed, 22 Jan 2014 15:18:03 +1300

[Angelicfury1 (angelicfury1)]

Thanks everyone. Can't wait for 14.04. Using nautilus in 13.10 is insufferable.

[Daniel Wyatt (daniel-wyatt)]

I'm pretty happy to see this in proposed too.
Thanks to Robert Ancell as well for helping merge this (fixing some of my mistakes).

Also, don't hesitate to nudge the nautilus people into reconsidering this:
https://bugzilla.gnome.org/show_bug.cgi?id=721968
https://bugzilla.gnome.org/show_bug.cgi?id=681871
(They quickly closed my patch submission as a duplicate of a 1.5yr old bug.)

[Blaster (holst-niels)]

Whenever developers shows lack of interest in use-case based "feature"-implementation, i just point them to this "bug". If the still don't get it, i'll tell them to open the "/usr/share/themes"-folder in Nautilus using just a keyboard. Most of them will just yell obscenities and set PCManFM or Thunar as their default file-manager.

Recursive search is a disaster implemented as a feature you can't opt out of. My personal opinion is that Nautilus should be dropped as default file manager in Ubuntu. I'll never trust that team again.

I might add that I'm personally not much affected by the "bug", since I use Midnight Commander. Thanks Peter Norton ;)

[Vaclav Petras (wenzeslaus)]

Thanks to the people fixing this bug, in the first place. However, I'm sorry to put it in this way but Blaster pointed out what is the real bug which caused this one. It is the strange policy in the Nautilus development. This might be fixed by changing the policy or changing the file manager in Ubuntu. Because otherwise, we must ask what will be next? Removal of Home (/home/user) from the side bar and leaving there only (My) Documents, (My) Music and (My) Pictures as it is on Mac OS and some (all?) MS Windows? Removal of possibility to show hidden (.*) files or removal of list view because everyone wants big thumbnail anyway, right? ...

I'm sorry to see developers spending their time reimplementing, debugging and fixing features which already had working implementations and were removed just few months before. I'm concerned that this state is not sustainable.

[Blaster (holst-niels)]

@Vaclav Petras (wenzeslaus) #91

For now the only solid fix for the bug is this:

1) Install PCManFM via Ubuntu Software Center
2) <ctrl>+<alt>+T or a terminal
3) Do this: (works on both Gnome Shell and Unity)

xdg-mime default pcmanfm.desktop inode/directory

sudo mv /etc/xdg/autostart/nautilus-autostart.desktop /etc/xdg/autostart/nautilus-autostart.desktop.bak

sudo nano /etc/xdg/autostart/pcmanfm-autostart.desktop

4) Copy-paste the following in the Nano-editor you opened in 3):

[Desktop Entry]
Type=Application
Name=File Manager PCManFM
Exec=pcmanfm --desktop
OnlyShowIn=GNOME;Unity;
NoDisplay=true

5) Save changes with <ctrl>+O, <enter>, <ctrl>+X

6) Do this in the terminal:

favorites=$(gsettings get com.canonical.Unity.Launcher favorites | sed 's/nautilus.desktop/pcmanfm.desktop/')

gsettings set com.canonical.Unity.Launcher favorites "$favorites"

7) pcmanfm --desktop-pref

Select your wallpaper. Note that for Gnome Shell the "stretched"-mode for the wallpaper works best.

Congrats! Nautilus is out of your life now.

[Daniel Wyatt (daniel-wyatt)]

Any chance this bug will be closed soon or is there a long review process? (I could use the bounty)

[Adam Dingle (adam-yorba)]

Daniel, I believe you should now be awarded the Bountysource bounty for this bug. It hasn't closed yet (probably because this bug still points to an open GNOME issue that is only semi-related), but I just emailed them asking to close the bounty. They're usually pretty responsive so I expect to hear back soon. In any case I expect we can resolve this with them directly. Thanks again for your help fixing this!

[Daniel Wyatt (daniel-wyatt)]

@Adam: Thanks, much appreciated!

[Teo (teo1978)]

I totally second comments #90 and #91
This bug demonstrates (if any more proof was needed) that Nautilus needs to be replaced with something else by default in Ubuntu (and in any distro trying to be of any use), quite urgently.

[Ajay Anand (aanand-ub)]

Jumping to the file beginning with the typed letter is NOT the best behavior.

Searching all the folders and subfolders when something is typed is also not the best behavior.

THE BEST BEHAVIOR IS:

Searching all the folders and subfolders when something is typed is the best behavior given a toggle button to enable/disable subfolder search. If subfolder search is disabled only current folder will be searched. This amalgamates best feature of both sides.

[Ajay Anand (aanand-ub)]

Until the best behavior (mentioned above) is incorporated, I recommend using the fallback mode: "grep" and "find".

[M4he (mahe)]

@Ajay: That's a rather subjective opinion! Search will always get slow on huge folders. Because of the technical nature of type-ahead it is still fast even on huge folder contents. When I use type-ahead it takes me less than 1 second to choose and enter a folder.
I know my folders and their subfolders, I'm dependent on the speed of type-ahead because I use a chain of multiple letter and enter key strokes to navigate through many folders in a second. If type-ahead would be replaced by search, the speed of search results would depend on the folder's content size and I would not be able to use my quick chain of key strokes anymore due to the irregular response time of the search.
I admit, this is a rather subjective opinion as well! But type-ahead has been there for years, it is also integrated into the file managers of OS X or Windows and into the majority of the Linux ones. Your solution mentioned might be an improvement for _some_ people. But that doesn't mean it should replace type-ahead. It could be added as an optional feature that can be activated within the settings. Linux software in general is about configuration & customization - not about claiming you know what is best by forcing your opinion on others and killing features. The latter is exactly what happened to nautilus and why we have this long discussion here.

[Sebastien Bacher (seb128)]

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1300308 is due to this change (ctrl-s in list view selects only one element)

[Max D (maxdesp)]

This is up to date again in 17.10

[drunckoder (drunckoder)]

I can confirm there's an issue again on Ubuntu 17.10

[Stathis Aliprandis (alistat)]

I can also confirm on 17.10 (3.26.0)

[teo1978 (teo8976)]

Fucking unbelievable

[Michael Borkowski (miuhael)]

17.10, this is annoying as hell.

[Birger Skogeng Pedersen (gromit190)]

As someone who constantly uses type-ahead find when browsing files, I can't stand the current behavior. Who actually wants it this way? I'm replacing Nautilus for now, please fix this.

[ju2gle (ju2gle)]

This is really awful!

[Henrik Holmboe (holmboe)]

The old behaviour was one of the power features of Nautilus for a person that uses keyboard navigation. The new behaviour is dramatically different and frankly doesn't work as well for many use cases.

Lets say I want to quickly navigate to ~/code/myproject/module/__init__.py.

1. I switch to Nautilus which shows my home folder
   A. With the old behaviour: c ENTER m ENTER m ENTER __i ENTER
   B. With the new behaviour: __init__.py, and it shows me tons of __init__.py located in my home folder and all subdirectories
2. Trying to use the new behaviour and still achieve my goal I try this:
   i) module/__init__.py, no hit
   ii) module __init__.py, no hit

So, currently I see no way of navigating to the intended file without alot of hassle or reaching for the mouse. A big regression for me.

[teo1978 (teo8976)]

@109 this is already known to be the wrong behavior. It was introduced long ago by the hopelessly stupid Nautilus people, and patched by Ubuntu to reestablish the old sensible behavior, but something must have gone wrong in the latest release and so the idiocy has resurfaced.
What I don't understand is how it can be taking so long to fix again.

Oh I see why: most of us cannot change back the status of the bug once it has been changed to "fix released" (which is stupid, too).

[Andrew Simpson (adpsimpson-gmail)]

> Oh I see why: most of us cannot change back the status of the bug once it has been changed to "fix released" (which is stupid, too).

If that is genuinely the reason (and this bug has been marked as "Fix Released" since Jan 2014, so it seems correct), then is it not time to raise a new bug?

[Henrik Holmboe (holmboe)]

@adpsimpson-gmail there is already #1666681: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1666681

[teo1978 (teo8976)]

> If that is genuinely the reason (and this bug has been marked as "Fix Released"
> since Jan 2014, so it seems correct), then is it not time to raise a new bug?

Maybe (though it seems a little stupid to raise a new bug for exactly the same issue).

Anyway I did, like yesterday, and it got closed
(can't find it right now, I don't know what's wrong with the search engine of this stupid bug tracker)

[Serge (ohmerton)]

Unfortunately this is really a deal-breaker for me and forces me to drop Nautilus and experiment with other, perhaps not so well developed/maintained, GUI file managers. What a pity.

[teo1978 (teo8976)]

"not so well developed/maintained"? You mean worse than Nautilus??

[teo1978 (teo8976)]

> Anyway I did, like yesterday, and it got closed
> (can't find it right now [...])

Here:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1754069

[Henrik Holmboe (holmboe)]

Perhaps a legit workaround: https://askubuntu.com/questions/980855/make-nemo-produce-desktop-icons-gnome-3-26-1-on-ubuntu-17-10

[Maxim Berman (bermanmaxim)]

Very often files many subfolders contain files with the same name as in the folder you are browsing. Example: Makefiles, .git folders, etc. With recursive search these files all show up without a clear way to distinguish them. :(

[Lubomir Brindza (lubomir-brindza)]

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

The changes are based on the patch from Arch community (https://aur.archlinux.org/packages/nautilus-typeahead/), with slight modifications to work on 3.26.3 release.

[Ljiljan Veselinovic (ljiljan-veselinovic)]

In Ubuntu 18.04 this problem is now present again :-( it is really annoying...

[Ljiljan Veselinovic (ljiljan-veselinovic)]

Why don't we have both options? Why removing something that we like (find folder/file with a letter) and insisting on something else (search)? I am trying to get used to this new behavior for almost a week, but it is just slowing me down.

This could be implemented as simple as this:

## keypress event

switch (option_search_or_locate ) {
  case 1: locate_folder (char_pressed); break;
  case 2: search (char_pressed); break;
}

[Starbeamrainbowlabs (sbrl)]

What's the status on this please? Someone seems to be maintaining a PPA that restores the functionality over at https://launchpad.net/~lubomir-brindza/+archive/ubuntu/nautilus-typeahead

....how hard would it be to just accept that version as the official version of nautilus?

Sounds to me like those in charge of deciding the direction of gnome / nautilus / etc. don't really think about the users as much as they should do - leading to useful features being regularly dropped (is there going to be anything left?) - this is far from the first time this has happened.

[teo1978 (teo8976)]

> Sounds to me like those in charge of deciding the direction of gnome / nautilus / etc.
> don't really think about the users as much as they should

They don't THINK much at all, let alone about the users.

[Henrik Holmboe (holmboe)]

@teo1978 could you please spare us your comments, they are offensive and does not help. Please only send constructive comments.

If you want to affect the right people into understanding your point of view, then you will have a much better chance if you are nice to begin with.

[teo1978 (teo8976)]

> Please only send constructive comments.

Here's a constructive comment: Ubuntu, as a distribution, should switch to another default file manager other than Nautilus, because Nautilus is poorly maintained and the upstream developers keep making bad design decisions that only make the software worse. Has been so for years already, and it doesn't show any signs of getting better.

[mkurz (matthias.kurz)]

Unbelievable.

Upgraded to Ubuntu 18.04 to find out about this crappy behaviour.

Please fix it.

[Norbert (nrbrtx)]

I can't completely understand what GNOME developers are trying to achieve!
This functionality was used for years.

Ubuntu 14.04 LTS and 16.04 are not affected.
But 18.04 LTS and 18.10 are trying to perform search after entering first letter.

The patch for Nautilus in 18.04 LTS is available (see https://askubuntu.com/q/275883/66509 and https://launchpad.net/~lubomir-brindza/+archive/ubuntu/nautilus-typeahead ).

[teo1978 (teo8976)]

> I can't completely understand what GNOME developers are trying to achieve!
> 18.04 LTS and 18.10 are trying to perform search after entering first letter.

The underlying assumption seems to be that when you type the name of a file, the only thing you may possibly want is to search for that file, and that if the search is recursive within subdirectory, that's even better, and that the only reason you may not want that, is because a recursive search can become slow; but since they have optimized search so much that it is always instant-fast (or so they claim), then who wouldn't want Nautilus to just start searching recursively and instantly showing you the search results as you type? Genius, right?

Wrong. Becaue even assuming a recursive search in a bazillion files could be performed in a nanosecond, that is not necessarily what we want when we type a partial filename. Many of us just want to SELECT a file within the current directory while still viewing all of its contents and not just the matching file/s. Perhaps you want to simply SPOT that file and select other ones that are near to it, or actually select that one but also other ones.

When you want to do a search, which is a completely different thing, you can do Ctrl+F.

[Andrew Simpson (adpsimpson-gmail)]

There is a fundamental difference between search (what you do when you don't know where something is) and navigate (what you do when you know exactly where something is, and want to go there). Why the gnome team have chosen to conflate them, and their mental state while doing so, is anyone's guess. But from a usability perspective, it is broken.

[Milton Lai (miltonlai)]

The most painful thing in Ubuntu 18.04. The search functionality is terrible when I just want to navigate to certain folder/file in a long list.

[Malac (malacusp)]

Please put this back in.

I never understand why developers /remove/ features instead of leaving them in and making it an option.

The previous org->gnome->nautilus->preferences setting accomplished this fine and should have been left active.

[anonymous mouse (eeefafe)]

OK. So I was a happy user of 16.04. With a new computer in August, I thought it would make sense to go with 18.04.

One of the biggest issues is this searching stuff in Nautilus. Why?
1. It is not instant (unlike the type/find ahead of Nautilus in 16.04). I cannot type and then press enter and load the folder I want.
2. It is inconsistent with file dialogs (e.g. save or open) where find/type ahead works as expected.
3. Often I just want to see the files and folders in relation to one another. I might want to see the files starting with 'th', and being able to see the files starting with 'te' and 'tg' before the ones starting with 'th' is often quite useful.
4. There is no way that I can see to make it search only within the directory and not recursively search all subdirectories. I don't like that.
5. And searching within subdirectories doesn't even work 100% of the time! E.g. A search for a dot folder consistently doesn't turn it up.

Thank you Ubuntu developers for previously hiding this stupidity. Please consider getting rid of it in 18.04 as well.

[Jan-Jonas Sämann (janjonas)]

This stupid behavior isn't only inconvinient,

-> this really BREAKS FUNCTIONALITY if you work on network resources.

Especially in Germany where possible internet speeds in many locations do not exeed well known dialup connection speeds.

What happens then is a complete lockup on nautilus while the filelists are queried again from the remote site. This usually takes minutes to complete.

[Allan Boll (allanrbo)]

+1. Type-ahead is basic expected functionality of a file browser.

[javier (javierleal)]

I changed to Dolphin :-(

[zhanghongce (zhanghongce)]

One more vote for a type-ahead navigation rather than a search. The search is stupid.

[CarlosRuiz_globalqss (carg67)]

I think the change is interesting - what seems annoying is to force the user - not letting us choose. In my case - installing back the old nautilus.

[आर्य (arya108)]

I installed a PPA that served as a workaround, until an update this morning. Now there is no type-ahead and the PPA does not work. One more vote for a type-ahead.

[teo1978 (teo8976)]

Why the fuck hasn't this been reopened yet??

[javier (javierleal)]

They do not think to fix It
:(

[teo1978 (teo8976)]

@Javier

if by "they" you mean the upstream Nautilus developers, that's right: they don't even understand it's a bug. The Gnome development team, or at least the part responsible for Naitulus, has proven many times to be a bunch of idiots. For the last several years, they have taken many design decision that completely destroyed the usability of their software.

But the Ubuntu team seems to be more intelligent. In the past they have patched several things in Nautilus and perhaps other Gnome products to fix the idiotic mistakes made upstream. This was one of them.

Now the question is: does Ubuntu consider it worth to keep doing the patching to fix the upstream idiocies in Nautilus? If that is the case, then this, among other things, needs to be fixed. Again.

If not, if they are going to rely on the upstream developers fixing upstream issues, then they must drop Nautilus in favor of some other file manager that is not maintained by a bunch of idiots.

[CarlosRuiz_globalqss (carg67)]

Please read https://www.ubuntu.com/community/code-of-conduct

[teo1978 (teo8976)]

Yeah right.

[Bruno Duyé (brunetton-gmail)]

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

I **CAN'T BELIEVE** that after more than 5 years there's still NO option to DECIDE what should be the default behavior of the default browser. And when I see the ridiculous patch [1] this implies, I can't believe it even less. What would be the cost of an option in program's preferences ?!

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

[teo1978 (teo8976)]

There's no need for an option.

You can already do a recursive search with Ctrl+F.
I "can't believe" one would want to enable type-ahead-recursive-search instead of type-ahead-select-in-current-folder by default just to spare themselves the trouble of hitting Ctrl+F.

However, an option, even if for enabling the weirdest preference or for accomodating the rarest use case, is always a good thing. What is absolutely unacceptable is a wrong default behavior that, even worse, cannot even be changed to the more sensible one. That is, the current situation.

I am stuck with 16.04 because upgrading to 18.04 would mean having to live with this crap, which is like living without a file explorer at all (that's doable for somebody accustomed to doing everyday tasks from a terminal, but that's not me, nor the average user).

[Chris Billington (cjbil1)]

I don't think it's true that an option is always good. I think software should endeavour to have decent default options, and if multiple use cases can be accommodated without an option, then that is preferable.

But you're right, a recursive search with ctrl-f vs typeahaed with simple typing would accomplish what everyone wants without an option.

I'm using the 'search in current folder only' setting in order to make the search more like typeahead, but this has the downside that I have to go into the settings to do an actual recursive search. In reality, recursive search is useful, and I want to use it, but it's different to typeahead and it's a shame I have to pick one or the other.

Ideally for me would be typing is just going to select things similarly to the old typeahead behaviour, and ctrl-f would do a search, either in the current folder or recursively depending on a checkbox that would ideally be in the main interface next to the search box rather than in the settings menu - since one often wants one or the other, it's not really an all-time preference.

I do think things will eventually go back this way. There is currently wasted effort trying to make search meet the requirements of type-ahead, whereas this would be unnecessary if typeahead existed too. Search is becoming a bit of a frankenstein trying to be both, with returning items from the current folder first, and having the search-in-current-folder-only setting being global. It should just be search - features should do one thing each instead of trying to please everyone.

I understand that search has been improved a lot in response to complaints about type-ahead being removed, and this shows that the devs are trying to meet people's use cases. But ultimately I think it is misguided and making the search implementation more complex than it otherwise would need to be. They are really are different features. So I know there has been a lot of vitriol over this issue, but I would encourage the nautilus devs to consider that they should become different features once again. Ctrl-f to search will not confuse anybody, type-ahead will not confuse anybody, whereas the current search is trying to be both and so can behave unexpectedly in terms of the order of search results and whether the search is recursive. Presumably this means code complexity too.

I also understand that the old type-ahead code was holding back the codebase and so it was desirable to excise it. I imagine new typeahead functionality, working as much as possible within the current codebase and its future directions, would be more amenable to nautilus dev approval than just restoring the old code. For example, we probably don't need the popup box in the bottom right as you type. It should just be type a few characters and have a few-second timeout before forgetting them, just like it is on other platforms such as windows and macos (I think). It seems similar to me to the case or removing nautilus handling the desktop. The code was holding back the codebase, but now we see that a desktop extension for gnome-shell is in development by the main nautilus dev.

I do think Nautilus can satisfy everyone's preferences here, an...

[Mihir Gadgil (mihir-gadgil)]

Is there any timeline as to when this stupidity is going to be fixed? This is a very very very basic functionality for any file explorer; something any new application should add. Taking it out of a software that has already had it for years and annoying people who rely on it is simply illogical.

[teo1978 (teo8976)]

> In reality,
> recursive search is useful, and I want to use it, but it's different to
> typeahead

Exactly, they are two completely different, unrelated things, and if the Nautilus devs can't understand something as elementary as that, Ubuntu shouldn't be using software developed by those people as the default file explorer.

This issue is just one example; nautilus developers have taken quite a few "design decisions" that are - ahem - let's say contrary to common sense, degrading usability rather than improve things.

Keeping Nautilus as the file explorer means Ubuntu will have to keep struggling with this sort of things and maintaining patches like this one. Of course, if there's no better alternative out there (I find it hard to believe that such a shitty file manager is the best available, but I don't know, it might be), then it'll have to be this.

> I do think things will eventually go back this way
> (...) I do think Nautilus can satisfy everyone's preferences here

How long do we have to wait for them to recapacitate and revert breaking stuff that had been designed correctly in the first place ages ago?

[Chris Billington (cjbil1)]

I don't know how long it will take, but in the meantime Ubuntu could ship the patch maintained by the Arch community:

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

It looks like this patch is kept up to date pretty well. There is a similar patch for gtk3 to make the file chooser dialog have type-ahead.

It's the best of both worlds, since you can still tap ctrl-f to search.

Whilst it would be nice for the Nautilus devs to upstream the patch or for there to be a dialog about what kind of patch they might accept (if any), in the meantime distros can include the patch, there is little downside since the patch is maintained and not bit rotting. Canonical would not be committing themselves to maintaining it by including it.

[Ads20000 (ads20000)]

This is an upstream GNOME bug (though you might want to make the case that Ubuntu should deviate from the default GNOME behaviour for this issue, in which case please open a new bug since I don't think standard practice is to re-open old bugs like this when it has been fixed in an Ubuntu release? I think you could reasonably tag the new bug as a regression. If you do make a new bug for this issue in newer Ubuntu releases then please link to it from here), please +1 (use the thumbs up button on the original Issue and comments that you agree with, don't comment a +1) the following issues to indicate your support for a restoration of type-ahead. On unlocked Issues you can also comment specific use-cases which a lack of type-ahead breaks and which the optimizations mentioned in https://gitlab.gnome.org/GNOME/nautilus/issues/246 and https://gitlab.gnome.org/GNOME/nautilus/issues/247 don't fix (if you think those optimizations would help your use-case then please +1 them). Specific use-cases where you absolutely NEED type-ahead search may change the developers' minds, if you don't have specific use-cases then just +1 comments on GNOME GitLab that you agree with, but we're unlikely to see much change in that case, we NEED specific use-cases:
https://gitlab.gnome.org/GNOME/nautilus/issues/8 (unlocked)
https://gitlab.gnome.org/GNOME/nautilus/issues/244 (locked)
https://gitlab.gnome.org/GNOME/nautilus/issues/466 (unlocked)
https://gitlab.gnome.org/GNOME/nautilus/issues/590 (unlocked)

[Grant Woodford (woodford-gw)]

I am switching to Nemo because of this.

[CarlosRuiz_globalqss (carg67)]

Agree with Grant, not easy, but doable.
I migrated to nemo 42 days ago following this guide:
https://www.linuxuprising.com/2018/07/how-to-replace-nautilus-with-nemo-file.html

I must say I can't be more happy :-)
Again things work as I would expect in a file explorer.
Typeahead works - but also the multi-tab that was dropped from nautilus some time ago - I missed that one too.
So, IMHO great decision.
I would love that ubuntu takes nemo as default.

These discussions are really weird, when the change can be easily solved adding a flag in preferences, and the discussion get hot with your community, not solving sounds like discussion evolved to ego issues.

[Tuomo Sipola (tuomosipola)]

Please bring this functionality to Ubuntu's Nautilus. Disco now has the distressing search functionality extended even to the save dialog.

The Gnome team is extremely resistant to bring back the old intuitive functionality. I tried to explain the problems at https://gitlab.gnome.org/GNOME/nautilus/issues/244 , as did many others. People are still requesting the old type-ahead thing, so the trade-offs have not been accounted for.

[teo1978 (teo8976)]

> The Gnome team is extremely resistant to bring back the old intuitive functionality.
> I tried to explain the problems at https://gitlab.gnome.org/GNOME/nautilus/issues/244
> , as did many others.

Trying to reason with the Gnome team is a complete waste of time.

That's why Ubuntu should either patch it, or drop Nautilus completely.

Why the f*** is this bug still in the "fix released" status? It should either be reopened or a new one created.

[Norbert (nrbrtx)]

+1 @teo1978 (teo8976)

Users will decide. The most radical solution would be purging the whole GNOME desktop and install MATE DE instead. I switched to MATE in 2013 and I'm completely happy with it.

In MATE the Caja file-manager (fork of Nautilus) has normal search even in 19.04. Also it has Extra Pane (acessible with <F3> key).
See https://askubuntu.com/a/1097974/66509 for removal process.

[ts (toto-23)]

So mate used to be great but doesn't seem to be a solution anymore either, type-ahead-find seemingly has been replaced for search-as-you-type in mate sometimes this summer as well, too.

+1 for replacement, it could at least be a configuration option

[Shevek (r-launchpad-anarres-org)]

This change has made the system effectively inappropriate for use in a business situation where mistakes are to be avoided. In the old system, searching within a folder for a file to send to a client would only list files from that folder. Now, file-open and so on show me files from ANYWHERE ON THE SYSTEM FOR ANY CLIENT WHATSOEVER, leaving the user a single mis-click away from a GDPR violation. Choosing a folder should set a boundary on the files displayed. If I want search, I'll search.

[Antonin Chambolle (antonin-chambolle)]

I think a nice way to solve this stupid debate could be to ensure that the files are displayed in a STABLE order
- type ahead results from the current folder first
- folders first
- files in the current folder before the other files...

what is MOST annoying with the current feature is that when you have spotted the file you're interested it (or quite often the folder) then
- there can be other files/folder with the same name and it is impossible to know which is relevant (it should be the closest, the one from the current folder, etc). It seems to be the last used, so it changes
- when you have spotted the folder or file you want to open, the time you move your pointer to open it the files are reorganized as further search has been done, and you open some other random file.

How is it possible to maintain such a feature the way it currently works? The search should be done in some order, and this order should not change so rapidly while you're trying to find your result...

[teo1978 (teo8976)]

Debate?

I haven't seen any debate.

And no, your proposed "solution" is no solution to the issue.
That's a good possible improvement to the search itself, but type-ahead should do select, NOT search for the obvious reasons that have already been pointed out which are not solved by your proposed improvements to the search

[Anton Gousier (agousier)]

SEARCHING IS NOT NAVIGATING, please. Besides the debate on whether the option to disable search when starting to type should exist (I think it should), #144 has raised quite an important side effect: searching should not make it look like files are deleted.

[CarlosRuiz_globalqss (carg67)]

This ticket was opened 7 years ago, and after 160 comments, nobody seems to care about.

I lost all my hope that ubuntu or gnome are going to take care of this, probably 259 affected people is too little for them.

I installed nemo 1 year ago, and didn't come back, I'm happy with nemo bringing me back the F3 shortcut to navigate two trees simultaneously, and the type-ahead behaving as expected, and at the same time being able to search with Ctrl-F.

Sad answer to community, but reading the history of gnome project it seems is not uncommon.

I see gnome resolved the related ticket as obsolete - so, probably would be better to do the same with this ticket here at ubuntu - and let people move ahead (to nemo) without false hope :-)

[teo1978 (teo8976)]

Actually this one is marked as fixed because it was indeed fixed several years ago, but then the fix was lost (i.e. the patch not rewritten) when a new version of gnome was released, "because" search is faster now, which according to some nonsensical reasoning by those who don't uderstand this issue, meant to them that the issue was no longer relevant.

[CarlosRuiz_globalqss (carg67)]

For reference only:

Old gnome bug resolved as obsolete:
https://bugzilla.gnome.org/show_bug.cgi?id=681871

Recent bugs opened with same topic:
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1157
- with 9 related tickets closed

https://gitlab.gnome.org/GNOME/nautilus/-/issues/1154

[Norbert (nrbrtx)]

The real fix for whole modern GNOMEs Hell is simple - do not use it.
Remove it (for example on 20.04 LTS with https://askubuntu.com/a/1233026/66509 ) and install normal DE instead - with Caja, Dolphin, Nemo, Thunar or whatever.

[amano (jyaku)]

Why can't you just move on? What is your stupid agenda?

[guy.brush (guy.brush)]

I don’t think anyone has an agenda here. People are searching for a way to give feedback and to communicate their frustration with this change. Obviously, this change which broke functionality that many users relied on caused quite a bit of frustration.

[Rolf Leggewie (r0lf)]

This discussion should be continued in the following places in a civil (!) manner.

Uncivilized language, no matter how angry you are, is likely only to have the effect of alienating the people in charge. It's in your own interest to stay civil if you want to get the old behaviour restored. No need for any comments, really, just upvote as "being affected" in the two below tickets if you'd like to see this problem fixed.

bug 1914962: replace nautilus with alternative default file manager
bug 1751069: restore type-ahead find in nautilus itself

[php4fan (php4fan)]

> bug 1751069: restore type-ahead find in nautilus itself

You have linked to the wrong issue.

[Gregory Kramida (algomorph)]

Perhaps @Rolf meant this bug?

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1754069