After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793497 - using tab completion when entering the path to a file should display the contents the directory that was completed
using tab completion when entering the path to a file should display the cont...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2018-02-15 22:49 UTC by jezra
Modified: 2018-05-02 19:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description jezra 2018-02-15 22:49:09 UTC
When using CTRL+l to manually enter the path to a file, tab completion of a directory name should result in the file view displaying the contents of the directory that was just completed
Comment 1 Daniel Boles 2018-02-19 10:07:45 UTC
It's supposed to be a completion suggestion. Forcing navigation to every suggested folder would seem to (A) break picking from among multiple suggestions and (B) further annoy people who already don't like how the FileChooser does various things without their explicit say-so.
Comment 2 jezra 2018-02-19 16:57:28 UTC
When the user presses the tab key, it is no longer a suggestion, it is a direct request by the user to focus on the given directory or file name. 

When the user uses the tab completion to go to a directory, the user's focus is on that specific directory and files within it. It would be nice if the filechooser could focus on what the user wants to focus on. 

for example: 
when the user tab completes to "~/Projects/MyNiftyProject/src", the user's focus is on the contents of the 'src' directory. Displaying the contents of that directory to the user would make it easier for the user to choose the file they want, and not require the user to remember the names of the files in the given directory.
Comment 3 Daniel Boles 2018-03-18 17:26:46 UTC
I see now that Tab only works if the suggested completion is the only possible match; if so, it deselects the text and puts the cursor at the end of the entry, but doesn't navigate to that location; if not, it just beeps.

Enter acts differently: it navigates to a singular match, or fills out the entry but does not navigate for one of multiple matches.

So, you can press Enter instead to get what you want.

Tab beeping and failing to do anything in the case of multiple matches seems a bit unhelpful to me; maybe that should be reconsidered as part of the question whether it should act like Enter does here.
Comment 4 jezra 2018-03-19 21:23:07 UTC
Pressing 'enter' will certainly result in the filechooser displaying the contents of a directory. At that point, the user must yet again enter CTRL+l in order to start using tab completion again. 

Allowing for tab completion to behave like pressing 'enter' (when a directory is selected) would decrease the necessary user interaction, and could be a benefit for users with limited motor skills.
Comment 5 GNOME Infrastructure Team 2018-05-02 19:52:30 UTC
-- 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/1032.