GNOME Bugzilla – Bug 386569
GtkFileChooser enters first file name into the entry automatically
Last modified: 2018-04-15 00:19:39 UTC
Steps to reproduce: 1) Hit Ctrl-O in something and look at the filename entry; 2) If the entry is not visible, click the Editor button, do open some file, and repeat step 1 (so you hit Ctrl-O and see the entry). Actual result: the entry contains name of the first file in the list. Expected result: empty entry, so you can enter filename using keyboard.
You need a directory without subdirectories to reproduce it. If there are subdirectories, then the first item in the list is a directory, and doesn't enter its name into the entry.
I can confirm. Using Ubuntu 12.10. Very annoying to have a file name filled in, it really slows down opening a file!
Created attachment 263696 [details] [review] GtkFileChooser: Don't always fill location entry When using the file chooser to open files, the file name of the first file in the tree view was selected each time you changed the current folder. This was OK for the case that the chooser only showed the path bar, but very inconvenient when you used the location entry for navigation and choosing files, because the selection-changed signal from the view caused the location entry to be filled with the name of the first file in the list. Notice: This problem only occurred when the first file in the list wasn't a folder or the chooser was set to open folders instead of files. To avoid this behavior make sure to *not* select the first row in the tree view after loading the content when the location entry is visible. Once the location entry is hidden again, make sure to select the first item in the tree view again, if it has no selection yet, so that for the path-bar-only case the first item is always selected automatically, like it was before this patch.
(In reply to comment #3) > Created an attachment (id=263696) [details] [review] > GtkFileChooser: Don't always fill location entry This is a quick go at this, I didn't test a lot. I thought just not selecting the first row at all in the case the location entry is visible is less complicated that blocking signals and what not. I'm sure there are still issues with this fix ...
Comment on attachment 263696 [details] [review] GtkFileChooser: Don't always fill location entry Sometimes it can be convenient to just press enter, and open the first selected folder, even if the entry is empty. So not selecting anything isn't a good idea ...
Created attachment 263725 [details] [review] GtkFileChooser: Don't always fill location_entry Only fill the location entry with the file name of the tree view's selected file when the selection was done by the user. When the file chooser action is GTK_FILE_CHOOSER_ACTION_OPEN, it selects the first file in the tree view once loading has finished. For this case we don't want it to insert the file name in the location entry, as it hinders efficient navigation using the location bar. To achieve this, use a priv variable to keep track of whether the selection-changed signal was caused by a user action or by the file chooser itself.
Created attachment 263733 [details] [review] GtkFileChooser: Don't always fill location_entry Only fill the location entry with the file name of the tree view's selected file when the selection was done by the user. When the file chooser's action is GTK_FILE_CHOOSER_ACTION_OPEN, it selects the first file in the tree view once loading has finished. For this case we don't want it to insert the file name in the location entry, as it hinders efficient navigation using the location bar. To achieve this, use a priv flag to keep track of whether the selection-changed signal was caused by a user action or by the file chooser itself.
Created attachment 263736 [details] [review] Corrected commit message, sorry for spamming this bug :)
Very nice patch. I like the idea of keeping a flag for this, at least until bug #492206 is fixed. I'll include your patch with a few modifications, as the following fails: 1. Create a little hierarchy like foo/ foo/somefile.txt foo/bar/ foo/bar/blah.txt 2. Go into foo/ and click on somefile.txt. 3. Double-click on bar/ At that point the location entry should be cleared, but it isn't. I think we just need to check for your priv->auto_selecting *inside* update_chooser_entry() instead of outside, as that function is also responsible for clearing the entry when switching folders.
Pushed to gtk-3-10 as 31da6d5d5, and to master as 70eb35d569.
I just tested, but the problem you describe here is not fixed, even with the change you made. We need to explicitly clear the entry.
Created attachment 264149 [details] [review] GtkFileChooser: Explicitly clear entry after loading Commit 70eb35d5696030271a0c76f85b705831fa6405de assured that in case of the GTK_FILE_CHOOSER_ACTION_OPEN action we don't fill the location entry with the automatically selected first row's file name when the model has finished loading. But that is not enough, we must also explicitly clear the entry case it was not empty before changing the directory.
Created attachment 264150 [details] [review] GtkFileChooser: Explicitly clear entry after loading Commit 70eb35d5696030271a0c76f85b705831fa6405de assured that in case of the GTK_FILE_CHOOSER_ACTION_OPEN action we don't fill the location entry with the automatically selected first row's file name when the model has finished loading. But that is not enough, we must also explicitly clear the entry for the case that it was not empty before changing the directory.
I wonder if we should clear the entry when navigating to the parent folder, too. (Only talking about GTK_FILE_CHOOSER_ACTION_OPEN again). Currently, when the entry contains a string that is not the filename of the last selected file, and you go to the parent folder with the pathbar, the 'custom' entry text will stay unchanged.
The whole issue with clearing the entry or not when changing folders is a bit tricky at the moment. It seems that some things work 'by accident' here and there, for example: when you are in folder B and go up one folder to folder A, you get a pending selection of folder B, which gets selected after the folder A's model has loaded, but the location entry is *not* (and that is right!) set to the name of folder B because B is a folder, not because B was a pending selection. That this is more 'working by accident' becomes clear when you look at the select folder mode: when you go up from folder B to A, you end up with 'B' filled in the location entry, which is not desirable.
*** Bug 723152 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new