GNOME Bugzilla – Bug 679865
Child folder is selected when navigating with pathbar
Last modified: 2018-04-15 00:11:12 UTC
When I'm in folder selection mode and I navigate up the hierarchy using the pathbar the new folder view has the directory I just came from already selected. This is not ideal because it make is hard to actually select the new (parent) folder. This is partly because there are two ways to select folders. You can click a folder to select it or navigate into it to select it. A simple solution for part of this is to not have an active selection (unset the selection) by default when navigating using the pathbar.
Good catch. This happens in gtkfilechooserdefault.c:path_bar_clicked(): static void path_bar_clicked (GtkPathBar *path_bar, GFile *file, GFile *child_file, gboolean child_is_hidden, GtkFileChooserDefault *impl) { if (child_file) pending_select_files_add (impl, child_file); if (!change_folder_and_display_error (impl, file, FALSE)) return; The pending_select_files_add() is what eventually causes the child folder to be selected in the new view. I *think* the code evolved in this way: 1. The file chooser wants to help you navigate the file list with the keyboard (Enter to go down a directory, Alt-Up to go to the parent folder). When going up in the hierarchy, you want the previously-visited child to be selected in the parent's list. 2. The path bar appeared. 3. The binding handlers for the up-folder, down-folder signals were redone to use the pathbar. See up_folder_handler() and down_folder_handler(), which simplytell the pathbar to go up/down. This in turn causes path_bar_clicked() to get called as a signal handler. So, it looks like the up-folder handler should add a pending child selection (the call to pending_select_files_add), and *then* call _gtk_path_bar_up(). In turn, path_bar_clicked() shouldn't queue the pending selection. (We still need the "child" and "child_is_hidden" arguments in GtkPathBar::path-clicked so that the handler can show hidden files if you navigate up from a dot-folder. Probably only child_is_hidden is absolutely necessary...)
*** Bug 553314 has been marked as a duplicate of this bug. ***
*** Bug 691774 has been marked as a duplicate of this bug. ***
*** Bug 540788 has been marked as a duplicate of this bug. ***
Created attachment 264942 [details] [review] GtkFileChooserDefault: Remove pending selections When navigating up and down using Alt+Down/Up, or clicking on the path bar, we don't need a pending list view selection of a possible child folder visible in the path bar, because the path bar already keeps track of the folder chain, and is used internally to handle all up/down actions.
Created attachment 264944 [details] [review] [PATCH] GtkFileChooserDefault: Remove pending selections We never need to add a pending selection here, as far as I can tell, since all user initiated up/down navigation uses gtkpathbar functions anyways and the path bar keeps track of the chain, right?
Comment on attachment 264944 [details] [review] [PATCH] GtkFileChooserDefault: Remove pending selections I thought that previous git bz attach had failed, sorry! It's the same patch.
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