You didn't describe what the problem is that you are facing.

Hello,

When I want to attach a file from Firefox I know where is the file, and start navigating from one directory to other, the first parent directory is generally ok the bookmark side toolbar

But then i write the first directory name and file chooser search through all muy ~60gb of files it display files thath I know that I dont want to use.

I prefer file chooser search would be only at current level. Without recursion. If Nautilus have such option, file chooser should have it too.

Thank you very much

Javi: while I do also want this feature, you are wrong about Nautilus having that option. The option does exist, but only in a patch that the GNOME developers didn't want to incorporate into Nautilus (for the same reasons they are against this option in the gtk+ file chooser, AFAIK).

Hello Jonas,

At Debian sid, nautilus-3.22.3, I can read the source, without patches applied:

$ grep  "search_recursive_never_radio" . -r -C3
./src/resources/ui/nautilus-preferences-window.ui-                  </packing>
./src/resources/ui/nautilus-preferences-window.ui-                </child>
./src/resources/ui/nautilus-preferences-window.ui-                <child>
./src/resources/ui/nautilus-preferences-window.ui:                  <object class="GtkRadioButton" id="search_recursive_never_radiobutton">
./src/resources/ui/nautilus-preferences-window.ui-                    <property name="label" translatable="yes">_Never</property>
./src/resources/ui/nautilus-preferences-window.ui-                    <property name="visible">True</property>
./src/resources/ui/nautilus-preferences-window.ui-                    <property name="can_focus">True</property>
--
./src/nautilus-preferences-window.c-
./src/nautilus-preferences-window.c-static const char * const recursive_search_components[] =
./src/nautilus-preferences-window.c-{
./src/nautilus-preferences-window.c:    "search_recursive_only_this_computer_radiobutton", "search_recursive_all_locations_radiobutton", "search_recursive_never_radiobutton", NULL
./src/nautilus-preferences-window.c-};
./src/nautilus-preferences-window.c-
./src/nautilus-preferences-window.c-static const char * const thumbnails_components[] =

And there is a radiobutton in preferences where you can select how nautilus should search. Maybe you are talking about other nautilus version ?

Thank you very much

Is it correct that this feature request is to allow typeahead instead of search-as-you-type in gtk3 file chooser dialogues?

Javi: Okay, sorry. I thought because you asked why people want "this feature" without further explanation over at #748672 you had just re-opened that bug on a different product / version.

I now looked through the settings of Nautilus and found what you were talking about (the "Search in subfolders" option in the last tab of the Nautilus settings). I didn't know that it was possible to change the behaviour of search-as-you-type in this way. And while this doesn't help with my personal main problem with search-as-you-type (I have to wait for the results to pop up between typing the prefix of what I'm interested in and pressing Enter), it seems like a valid request on its own to have that setting for GtkFileChooser as well.

(In reply to Jonathan W from comment #5)
> Is it correct that this feature request is to allow typeahead instead of
> search-as-you-type in gtk3 file chooser dialogues?

Not sure, I would like gtk3 file chooser not search recursively through all my files, only on the directory where it is.

Well, I found two workaround to this issue. First is having on clipboard the path, and paste (CTRL-v) it inside file chooser. I would like that if you paste a complete path to a file file choose would navigate to the folder and select the file, so you can change the file choosed inside the same folder.

The second workaround is to type "/" and then write the path

Thank you

(In reply to Jonas Platte from comment #6)
> Javi: Okay, sorry. I thought because you asked why people want "this
> feature" without further explanation over at #748672 you had just re-opened
> that bug on a different product / version.
> 
> I now looked through the settings of Nautilus and found what you were
> talking about (the "Search in subfolders" option in the last tab of the
> Nautilus settings). I didn't know that it was possible to change the
> behaviour of search-as-you-type in this way. And while this doesn't help
> with my personal main problem with search-as-you-type (I have to wait for
> the results to pop up between typing the prefix of what I'm interested in
> and pressing Enter), it seems like a valid request on its own to have that
> setting for GtkFileChooser as well.

Sorry maybe I'm mixing concepts. I did not know that I was reopening that bug.

Thank you

Javi: You aren't! Like I said that's what I first assumed, incorrectly. Sorry for causing confusion.

If I understand correctly, this issue requests more or less the same thing as the other bug, even if it's not technically reopening the same issue, right?

I have a well structured directory tree in my Documents folder and I know the names of my files. I don't need a full text search with every open/save window but I need the ability to select my files fast by typing single characters!

Jonathan W: I think both bugs were opened for mostly the same reasons, but this one asks for a different solution. #748672 is about bringing back type-ahead (as an option) and this is about extending search-as-you-type with an option to not do a recursive search (which is a feature in Nautilus, in contrast to type-ahead).

Is there a difference in behaviour between search-as-you-type without recursion and type-ahead?  Or, I guess they're different visually, you can use non-recursive search-as-you-type essentially the same as type-ahead in terms of keystrokes?

Yes, there is at least one difference. This still applies when recusion is disabled:

> I have to wait for the results to pop up between typing the prefix of what I'm interested in and pressing Enter

(In reply to Jonathan W from comment #10)
> If I understand correctly, this issue requests more or less the same thing
> as the other bug, even if it's not technically reopening the same issue,
> right?

I think for me two solutions are valid. Type-ahead and disable recursive search which could be implemented as 'filter' (like quick filter on thunderbird.

Thank you

The search lists hits from the current directory first, and you can stop the search at any time. Why is that not sufficient ?

(In reply to Matthias Clasen from comment #16)
> The search lists hits from the current directory first, and you can stop the
> search at any time. Why is that not sufficient ?

It is faster if only read the folder where it is. It don't need to track all my folders (if you choose this option)

I would like to have a very light disk usage. Not need to examine every file on my home directory

I have more than 500 000 files, reading all the file headers (I'm not sure, maybe you have a database (tracker or how it is named now)), but I would prefer have not wait to read the result

$ time find proyectos/ | wc -l
517619

real	0m54,001s
user	0m1,016s
sys	0m3,656s

$ time find proyectos/ -maxdepth 1 | wc -l
23

real	0m0,039s
user	0m0,004s
sys	0m0,000s


Thank you for consideration

(In reply to Matthias Clasen from comment #16)
> The search lists hits from the current directory first, and you can stop the
> search at any time. Why is that not sufficient ?

(In reply to Matthias Clasen from comment #16)
> The search lists hits from the current directory first, and you can stop the
> search at any time. Why is that not sufficient ?

I guess it's a matter of what you want to put up with in terms of time and CPU resources wasted. 

I wrote a long reply first, but this basically sums it up perfectly:

> I have to wait for the results to pop up between typing the prefix of what I'm interested in and pressing Enter

As an example: I have a text file I want to upload to a bugtracker (just yesterday). It's called xrandr.log. When the file picker opens, previously I could just press x and enter, knowing that's the only file in my home directory beginning with x. Now I have to make sure it actually chooses the right file first. If I just write x, it will happen to place the file "gdb.txt" first, etc. I imagine on slower machines, an additional factor might be lag induced by the search. I can write "xra" immediately, and depending on what files I have and what the search string is (currently "xra") the likelihood is higher or lower I'll find it quickly or not. 

Another example: Say I have two files, testxrandr.log and xrandr.log. If I just want the latter, previously I could just type  x or xra and enter. Now, if I write "xra", I even get teh testxrandr.log file first. 

I don't really understand the reluctance against fixing a regression in terms of how quickly you can do something. I'm not arguing from a position of "this was normal always so it should exist always". It's simply faster (in some situations) and could be kept as an option, without hurting anyone. Historically, there was a reason for having a distinction between selecting files in a folder by typing their beginning characters, and searching for a file in the entire filesystem. 

All the above just deals with time spent by the user. In addition, there's the use of resources as mentioned by Javi. It seems wasteful to spent CPU and disk cycles on searching searching all files every time I use the file picker.

So there seem to be at least two or three reasons being discussed in favour of this request:

1a. It's less resource-intensive if it's not searching recursively.

1b. Because of 1a, it's much faster to use if it's not searching recursively (user experience)

2. You can predict what you'll land on when you navigate your directory structure if it's not searching recursively (which increases the efficiency of the user experience).

I'm afraid I have to agree with Javi and hd that the current behaviour is "sufficient" only for some use cases.  I would assert that many users in many use cases will find it faster and more intuitive to have a non-recursive search, or even the old behaviour of simple look-ahead.  It's also a much less resource-intensive option, so users with non-bleeding edge machines or enormous directory structures find the current behaviour too heavy on resources to be useful.

Sorry, I don't think this is fact-based. What the commandline tool find does has no relation to what is happening in the file chooser.

The file chooser is not hitting your disk at all to find matches in the already loaded current directory.

(In reply to Matthias Clasen from comment #20)
> Sorry, I don't think this is fact-based. What the commandline tool find does
> has no relation to what is happening in the file chooser.
> 
> The file chooser is not hitting your disk at all to find matches in the
> already loaded current directory.

As I said I wasn't sure what algorithm is implemented on file chooser. 

I dont understand why you implemented this on nautilus but not on file chooser. I think It is a good idea sharing this config. I dont like to see more file names that those that I hope to view. While the window is open and every time i send a keystroke I sense file chooser os reading folders under the folder where i want it to search.

Close as dont fix if you think It is not useful. Other people than me think that it would be

Thanks

> Close as dont fix if you think It is not useful. Other people than me think that it would be

I think the issue here is less about how useful Matthias thinks it is and more that he doesn't want to deal with it, and is annoyed that he's been one of the the only one who seems to want to deal with this code at all.  It would also in some ways undermine some of the work he's already done on this code.

None of this is how Open Source is supposed to work (a single gatekeeper, hurt prides, annoyance at maintaining code, arguing with users that the devs know best, etc.), and is indicative of a project that's not doing a good job at maintaining sustainability.

> The file chooser is not hitting your disk at all to find matches in the
> already loaded current directory.

What about the recursive search?  The speed at which it loads results makes me want to agree with Javi that it appears to be hitting the disk.

(In reply to Matthias Clasen from comment #20)
> Sorry, I don't think this is fact-based. What the commandline tool find does
> has no relation to what is happening in the file chooser.
> 
> The file chooser is not hitting your disk at all to find matches in the
> already loaded current directory.

The point is rather that it takes longer to select exactly the file you want, if you know its prefix, using the "old" way of doing it, even though it strictly speaking searches the current directory first, due to how it searches (not only by prefix, but entire filename). 

Additionally, arguably it is more CPU and disk time intensive (it starts searching ALL files and you need to manually cancel it with the cursor every time). 

I'm pretty sure getting patches submitted wouldn't be the problem, as I've seen that distros have tried triaging this behaviour already.

(In reply to Javi from comment #21)
> (In reply to Matthias Clasen from comment #20)
> > Sorry, I don't think this is fact-based. What the commandline tool find does
> > has no relation to what is happening in the file chooser.
> > 
> > The file chooser is not hitting your disk at all to find matches in the
> > already loaded current directory.
> 
> As I said I wasn't sure what algorithm is implemented on file chooser. 
> 
> I dont understand why you implemented this on nautilus but not on file
> chooser. I think It is a good idea sharing this config. I dont like to see
> more file names that those that I hope to view. While the window is open and
> every time i send a keystroke I sense file chooser os reading folders under
> the folder where i want it to search.
> 
> Close as dont fix if you think It is not useful. Other people than me think
> that it would be
> 
> Thanks

Sorry if my comment sound rude. It is not my intention.

Please, see this test, after turn on the computer (Debian Sid), I execute zenity and pick "Proyectos" from Bookmarks and search "sevilla"  and wait until timeout kill zenity (10 seconds)

javi@fideo:~$ timeout -s 15 10 strace -f -o zenity-file-selection00.log -e trace=file zenity --file-selection "Test"
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
javi@fideo:~$ grep -c proyectos zenity-file-selection00.log 
3570
javi@fideo:~$ timeout -s 15 10 strace -f -o zenity-file-selection01.log -e trace=file zenity --file-selection "Test"
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

javi@fideo:~$ grep -c open.*proyectos zenity-file-selection00.log 
527
javi@fideo:~$ grep -c stat.*proyectos zenity-file-selection00.log 
2857
javi@fideo:~$ grep -c stat.*proyectos zenity-file-selection01.log 
16327
javi@fideo:~$ grep -c open.*proyectos zenity-file-selection01.log 
3583

Sincerelly I though number of stat / open would be less than I can see:
$ grep -c "stat\|open" zenity-file-selection00.log zenity-file-selection01.log 
zenity-file-selection00.log:6234
zenity-file-selection01.log:24893

Some files on proyectosare opened some times:
$ grep open zenity-file-selection00.log | grep -o "\"[^\"]*\"" | sort | uniq -c | sort -n | sed 's,".*proyectos.*","file-inside-projectos",' | tail -n 5
      4 "file-inside-projectos"
      4 "file-inside-projectos"
      5 "/etc/ld.so.cache"
      5 "file-inside-projectos"
    641 "/etc/localtime"
$ grep open zenity-file-selection01.log | grep -o "\"[^\"]*\"" | sort | uniq -c | sort -n | sed 's,".*proyectos.*","file-inside-projectos",' | tail -n 5
     10 "file-inside-projectos"
     14 "file-inside-projectos"
     14 "file-inside-projectos"
     17 "file-inside-projectos"
   2006 "/etc/localtime"

Not idea why zenity read all the time /etc/localtime, which library need to read localtime every ~ 5 ms ?

Thank you very much and thanks spending time replying to this bug

Sorry again for my rude reply

When the search failed to highlight the wanted file/directory, not need 2,3 more keystrokes and to highlight it (not mentioned the search continuing hitting your disk during the time). Not to mention the order of the files is also messed up that I sometimes just give up find the file/directory with my mouse...

I believe this single reason is enough as the current behavior simply broke the efficient workflow with no comparable replacement. It have been mentioned multiple times in the old threads but was ignored. There was a long time ago where I do not even have to focus the gtk file chooser to choose my files.

Now I found my self selecting the file with my file manager and copy its path to the file chooser, then paste its path the file chooser. It is much faster.

It has been a while since the new behavior is introduced but many people still have problem with it. Maybe, just maybe, something is wrong?

Looks like I accidentally commented on the wrong issue! Sorry about that...

This is what I wanted to say:

I'd like to +1 Jonathan, Stefan and Daniel's comments. The new behaviour is very hard to use and essentially breaks directory navigation with tab completion.

The "Search -> Search in subfolders -> Never" option is better than the default, but then tab completion in the file dialog doesn't work.

It is entirely expected that changing behaviors is causing some amount of complaints from people used to the previous behavior. That doesn't mean we need bring back the old behavior, or even worse, add an option to choose between old and new.

> complaints from people used to the previous behavior

Matthias, it's not about that.  It's about the new method not adding any benefits for most workflows, and in turn being resource intensive, slow, and unpredictable.

We can argue about tastes and preferences for the next ten years (sorry, not taking the bait), but these three down sides are easily measured, and you have yet to state (at least on this thread?) what the advantage of the new approach is.

On the contrary, there is also the pitfall of someone wanting a new feature simply because it's new. Is there any evidence at all that that's not the case? I've been searching this issue and all I find are accusations that those who want the old behavior are just nostalgic, while they're actually giving practical examples and arguments about reduced efficiency. All while those who defend the current behavior have failed to deliver even a single coherent argument (that I can find) to justify it. It's entirely a one sided argument.

At best I can see this being useful to slower users who are unaware of the state of their own file structure. I cannot think of a single case in which this benefits someone who knows where their files are.

This issue seems to be split right down the middle between the 2 different ways of thinking about "user friendly". It's not all just about new users.
As someone who knows what I'm doing, knows where all my files are, and wants to get stuff done quickly, the removal of typeahead is absolutely user-UNfriendly.

Furthermore, I'd be curious to hear a justification for the complete removal (rather than just making it a secondary option) of a standard which has been present not only on previous versions of GTK but across countless pieces of software on other GUI toolkits and even other operating systems. Is there some technical conflict between this new search behavior and the old typeahead behavior which makes it exceedingly difficult to have both? I can only imagine that returning the old behavior would be trivial and would have negligible impact on the codebase. So why has my choice been removed?

I think if this is going to be considered "not a bug" we all at the very least DESERVE reasonable answers to the following:
1) A coherent argument about who, and under what circumstances, the new behavior is designed to benefit.
2) Why the old typeahead behavior cannot be maintained as an option for those who want it.

Hi Matthias,

I was trying so save this page:

https://www.psychologytoday.com/blog/fulfillment-any-age/201703/the-mindset-makes-it-hard-admit-youre-wrong

into my Documents/info/things/everyone/should/read/

And here's what's happened in the save dialog:

-I start typing 'Documents' and while I'm doing that, the dialog already bogs down searching my 550,000 files home structure regurgitating every thing that's has 'Doc' in the name or path. My system is slowing down. (While this is happening I have time to wonder why it's bothering bringing up filenames when I'm interested in finding a folder name to save to.)

-While it's doing that, I see the "Documents" folder so I double-click on it (still in the save dialog). So the save dialog stops its scanning and opens Document.

-I start typing 'info' and while I'm doing that, the dialog bogs down searching my 500,000 Documents structure for anything with 'inf'. My System is still slow. I see 'info' do I double-click on it. The save dialog stops its scanning and opens it.

-I start typing "things" and the dialog bogs down scanning by 400,000 info files for anything with "thi" in it. My system is still slow.

[...edited for brievety...]

-2 minutes later, I've finally worked my way down to the desired folder and save my file.

-by this time my wife (who is laughing at me while looking over my shoulder) asks me to save the same page to her Windows 7 machine (not that she is ever wrong, you understand, but still that page is interesting reading).

-so I get on her machine, click File->Save, type "Doc",enter,"inf",enter,"th",enter,e,enter,shou,enter,r,enter and 10 seconds later the page is saved.

(In reply to Matthias Clasen from comment #28)
> It is entirely expected that changing behaviors is causing some amount of
> complaints from people used to the previous behavior. That doesn't mean we
> need bring back the old behavior, or even worse, add an option to choose
> between old and new.

Even if this new behaviour is (appears) not to be an improvement or even a deterioration?

While I could imagine some advantages for 'open file' (for reading) operations I don't see any for 'safe file' - why would I choose an existing file name here?

How am I used to use such dialoges:
- starting with a known/pinned folder I click my way to the desired one and
- for saving then I simply start typing the file name or
- for opening (for reading) clicking onto the desired file (here search could indeed be helpful to reduce the number of choices)


From my point of view, every kind of automatism should at least have an option to disable it - "every feature is a bug unless it can be disabled"


So please make the search behaviour disableable (at least for 'safe file' operations.

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

petrelharp made a very good point at Bug 772634: that this not only has implications for performance and annoyance - but also privacy/confidentiality:


(In reply to petrelharp from comment #0)
> I realize this choice has been extensively discussed, for instance, in
> #754302 (so, apologies). But as far as I see, those bugs are closed, and I
> haven't seen the following issue addressed, and it's a major bug for me (and
> others; see last comment in #680118).
> 
> Use case: I am teaching a class that involves live demonstrations using
> libreoffice.  Consider the following situation: I would like to open the
> file 'example_data.ods', which is in my home directory.  I open libreoffice,
> do File > Open.  Say it starts in my home directory, and I start typing
> 'ex'.  However, the other files that show up when I do that are
> 'excrutiatingly_embarassing_filename.ohno' and
> 'extremely_sensitive_filename.whoops'.  As a result, I resolve to never use
> the file chooser in libreoffice again.
> 
> This doesn't apply only to people with erotic filenames (I don't): in a
> professional setting, it can be embarassing to show, the names of letters of
> recommendation one is writing, or names of job applications.  A workaround,
> of course, is to scrupulously remember to *not* start typing in the file >
> open dialog... but under pressure, giving a presentation, this is difficult.
> 
> As for how to resolve this, all I can think of is a preference to disable
> recursive search, as nautilus has done.  Yes, I know:
> http://ometer.com/preferences.html , and apologies.

I still think this is a major problem! The fact that it takes a noticable amount of time to come up with the files makes the potential for embarrasment worse.

To sum up:

 - recursive search can be slow, as it has to walk through the file system if there's no search backend like Tracker
 - privacy concerns with results coming from unrelated folders

Ideally, we could have something like the Nautilus search options that went into 3.20: https://csorianognome.wordpress.com/2016/02/08/nautilus-3-20-and-looking-forward/

It would be great if somebody could work on this.

fwiw, while I suspect it is not the preferred solution, Milan provided a patch that uses a FileChooser GSetting that can be disabled to replace recursive searching with the more traditional type-ahead (jump, etc.) rather than just non-recursive search, at Bug 753892:

https://bugzilla.gnome.org/attachment.cgi?id=370575&action=edit

That element of that bug is probably a dupe of some other though. I would mark it as such if not for the oddity about having to press Esc twice to cancel a search, which I'd like to figure out at some point.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/839.