GNOME Bugzilla – Bug 753892
Cannot quickly move between shown list of files and folders
Last modified: 2018-05-02 16:41:26 UTC
This is with gtk3-demo of gtk3-3.17.7-1.fc24 Steps: a) run gtk3-demo -> Pickers b) click File chooser c) select the home directory in the left "favourites" list (or any other where are files) d) click one file, thus the list of files & folders has focus e) start typing a file name you see few lines below or above the selected line Problem 1): Instead of having the cursor positioned on the first match, thus I would be able to use Enter and move on from these odd times, I'm presented with a search banner which gets focus, thus forces me to use more keys to achieve what I want, because what I want is to use only Enter, eventually cursor keys to position to the right file, not to Tab, Escape, use mouse or any other unhelpful thing. Problem 2): the folder listing is filled with items which are not in that folder, making it even harder to figure out which file is the right one. Problem 3): the first Esc press does visually nothing (the search bar was filled with two letters, "te" in my case), only the second Esc press hides the search bar Problem 4): repeat a) - d), then start typing "te" (quotes for clarity only). Then press Esc (twice, see problem 3)). Start typing "te" again. The outcome is that the 't' from "te" is eaten and you are presented with an "e" in the search bar in contrast of the first "te" typing, where were left whole "te" there. Problem 5): after tabbing in, I can still write letters, which are added to the search bar, while the focus is left in the listing - that is okay, but once I write too much, thus no hit is found, I cannot correct it by other mean than focusing the search bar, while backspace works when the listing in shown (has at least one file shown). While the Problem 3), Problem 4) and Problem 5) are not that crucial for me, the Problem 1) is a big usability hit for me, even bigger than completely non-working feature in 3.16.x (bug #750083). Remember, I had focused the listing, thus I want to do the thing in the listing and no where else. The current behaviour is not smart, it's just resource expensive and making things harder for such simple human beings like me. My usual use-case is that I know I have a file in *one folder* which is somehow named, thus I type the name I think it is, and then I can realize I'm wrong, it's not e-foo, but e-bar, which made me realize that as soon as I typed e-f, when I could just move few lines above and be where I wanted to be, while with the forced filter-out feature I'm completely lost. If you think I remember each single file name in my system then I'm sorry to tell that, but you are wrong.
ad 3): the first Esc stops the search. The cursor changes and the spinner disappears.
I can replicate 1~3. (In reply to Matthias Clasen from comment #1) > ad 3): the first Esc stops the search. The cursor changes and the spinner > disappears. True, but the 1st Esc is also required, yet redundant, even if the cursor/spinner already reverted, so there's nothing for it to cancel. I can't replicate 4 or 5: (In reply to Milan Crha from comment #0) > Problem 4): repeat a) - d), then start typing "te" (quotes for clarity > only). Then press Esc (twice, see problem 3)). Start typing "te" again. The > outcome is that the 't' from "te" is eaten and you are presented with an "e" > in the search bar I can't make it lose the 1st char typed like this. > Problem 5): after tabbing in, I can still write letters, which are added to > the search bar, while the focus is left in the listing - that is okay, but > once I write too much, thus no hit is found, I cannot correct it by other > mean than focusing the search bar, while backspace works when the listing in > shown (has at least one file shown). I can't make it do this. The focus always switches to the location entry when characters are added to it. What about you, on 3.22?
(In reply to Daniel Boles from comment #2) > I can replicate 1~3. Thanks for looking into this. It's a long time since I filled this bug report, I retested with gtk3-3.22.29-1.fc28.x86_64 now. It's expected that some thing may changed meanwhile, which is good. With respect of 1), I understood that it's currently the way gtk+ "forces" for the users and that some of them may prefer it. I guess it's a good candidate for an option, like "Sort Folders before Files". > > Problem 4): ... > > I can't make it lose the 1st char typed like this. Neither do I now. > > Problem 5): ... > > I can't make it do this. The focus always switches to the location entry > when characters are added to it. Same here. One thing I noticed when testing problem 5): the selected item is always reset to the first in the list when the search term is changed, even if the previously selected item is still in the regenerated list. Imagine a folder where are files test1, test2 and test3. When I type "te", then these three are shown. I can tab and select the second (test2 file) and when I either type "s", to have the search term "tes" now, or when I use backspace, thus I have search term "t" now, then the selection is reset to "test1", even "test2" is still part of the view. As I said at the top, it's good that some issues reported here got already fixed and/or improved. Thanks for it. You may consider some of the problems just a matter of my taste and habits, but at least the problem 1) hits my "performance" significantly, because instead of type&move I rather scroll to the right file, which is a pita with a folder which contains 196 files (it makes ~160.000 files with the subfolders of that folder (using `ls -Rla | wc -l` results in 162818), which is a significant performance hit when gtk+ tries to search in subfolders for a thing I'm not interested in at all and the CPU/disk makes it hear when gtk+ tries to traverse such large folder structure). Also, the filtering can be made smarter when the search term is made longer while the whole folder structure is already traversed, because you can simply limit what you see from the set you already gained, there is no need to traverse the folder structure again. Or if you do that, then do not cleanup the model. I see that re-fill on CPU usage and the view as such is flashing.
Thanks for the update! It's good that 4/5 are OK(ish!) now. Indeed, a lot of this is a matter of opinion (which, btw, I'd prefer type-to-jump rather than -search, but that means nothing). Saying that, since #3 seems to be a gremlin, it seems worth keeping open for that, if nothing else. About the performance when searching: * You mentioned not caring about subfolders. See Bug 784029 for a request to disable that, only search the current dir, for perf & privacy/security reasons * I don't immediately recall any bug open for, if not changing the current model, then ways to improve its performance. Maybe you'd like to open one?
(In reply to Daniel Boles from comment #4) > * You mentioned not caring about subfolders. It's not only that. I have a folder with files with common prefix. With type-to-lookup I can get near the desired place and use cursor keys to move to the right file, but with type-to-search the view can hide what I'm looking for, like when I do not remember the file name precisely, I only know that it was around prefix "evo", thus when I type it I could see it was "ews" prefix instead. I mean, there are several use cases where the type-to-search is counter-productive.
Created attachment 370575 [details] [review] proposed patch for problem 1) This patch adds a file chooser option "Type to Search in Folders", which is on by default (to keep the current behaviour), and when it's set to off, it behaves as expected to address problem 1) described above.
> If set to true, then typing text will search in folders, instead of look up in the current folder listing I take it that "look up in the current folder listing" means not to search but without recursion, but rather to simply jump to the next item matching the typed character?
(In reply to Daniel Boles from comment #7) > I take it that "look up in the current folder listing" means not to search > but without recursion, but rather to simply jump to the next item matching > the typed character? Correct. The built-in GtkTreeView search feature is used (gtk_tree_view_set_enable_search(), gtk_tree_view_set_search_column()), which doesn't change content of the model/view being used, only moves selection between visible nodes as needed.
(In reply to Daniel Boles from comment #2) > I can replicate 1~3. > > (In reply to Matthias Clasen from comment #1) > > ad 3): the first Esc stops the search. The cursor changes and the spinner > > disappears. > > True, but the 1st Esc is also required, yet redundant, even if the > cursor/spinner already reverted, so there's nothing for it to cancel. Here are the 2 sets of notable things that happen for each of the required 2 presses of Escape: [search for something, then press Esc twice:] filechooserwidget.c browse_files_key_press_event_cb Esc search_entry_stop_cb search_stop_searching filechooserwidget.c browse_files_key_press_event_cb Esc search_entry_stop_cb operation_mode_stop [wut] search_stop_searching search_stop_searching [wut] operation_mode_stop [wut] Current folder changed : file:///home/daniel/Downloads
-- 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/568.