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 376121 - Clicking folder in path bar doesn't select that folder as the target
Clicking folder in path bar doesn't select that folder as the target
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
: 448591 693387 776373 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-11-16 22:17 UTC by Mike Williamson
Modified: 2018-05-02 14:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mike Williamson 2006-11-16 22:17:56 UTC
I believe that the folder chooser that is used when extracting in file-roller, selecting a folder when taking a screenshot, etc. is unintuitive. If a folder is selected in the right hand pane, then hitting Open will use the selected folder. However, if a folder is not selected, then Open will use the current folder. This, to me, appears to be unnecessarily confusing behaviour.

For example, if my home directory is open, and no other directory is selected, hitting open will result in /home/user/ being used. However, if I then select a directory (without opening it), it will then use the selected folder.

Perhaps a problem this raises is that if you go up the 'trail' at the top (that
shows the parent directories), it can also be confusing. For example, I want to
save something in my home directory, but I accidentally navigate to the Desktop
directory. I then assume I can just go back to /home/user using the 'trail',
but this is not the case. Since going back in the trail automatically selects
the directory that you came from (i.e. going to user from Desktop using the
trail will result in Desktop being selected), you actually have to go to /home
in order to select /home/user. [Although you can, in this case, just use the
Places down the left hand side, this is clearly not viable for most
directories]

I hope I've made my point clear!

A possible solution might be to use a tree-like structure, like the tree mode that can be used in the left hand pane of Nautilus.

Thanks

Other information:
Comment 1 Guillaume Tissier 2007-04-09 09:57:47 UTC
Your message's very clear
People like my family who're using gnome now can't understand that, I've to help full time they want to extract something, save all attachements from on email, because it's impossible for common user to understand this stuff terminology.
I think it's a MAJOR SEVERY BUG if we want gnome to be user friendly, that "open" button click takes current folder as a selection.
Can't understand this kind a thing :( :(
Comment 2 Mike Williamson 2007-04-09 15:33:11 UTC
Still true on Foresight 1.1 (GNOME 2.18, GTK+ 2.10)
Comment 3 Federico Mena Quintero 2007-04-09 20:48:10 UTC
We need to replace the current scheme in SELECT_FOLDER and CREATE_FOLDER modes with a tree of folders.

  - /
    + etc
    - usr
        bin
      + lib
      + share

The internal GtkFileSystemModel supports this already, but it hasn't been used in that mode for a *long* time.  Someone just needs to enable this and debug it.
Comment 4 Michael Chudobiak 2007-06-18 20:14:50 UTC
*** Bug 448591 has been marked as a duplicate of this bug. ***
Comment 5 Michael Chudobiak 2007-07-01 11:32:50 UTC
*** Bug 452751 has been marked as a duplicate of this bug. ***
Comment 6 Federico Mena Quintero 2010-08-11 18:56:35 UTC
For reference, see bug #557689 for the problem where you get a file chooser in SELECT_FOLDER mode, and immediately clicking "OK" or "Open" doesn't work.
Comment 7 Matthias Clasen 2013-02-11 06:23:48 UTC
*** Bug 693387 has been marked as a duplicate of this bug. ***
Comment 8 Taegil Bae 2015-09-07 06:00:53 UTC
This is true for 2.24.28, 3.16.6.
I think that this issue can be fixed by deleting the following lines in path_bar_clicked() function:
  if (child_file)
    pending_select_files_add (impl, child_file);

Why are these lines needed?

I suggest that child_file be not selected, just shown by scrolling the view.
Comment 9 Daniel Boles 2017-09-14 10:40:34 UTC
*** Bug 776373 has been marked as a duplicate of this bug. ***
Comment 10 Daniel Boles 2017-09-18 18:20:44 UTC
(In reply to Mike Williamson from comment #0)
> Perhaps a problem this raises is that if you go up the 'trail' at the top
> (that
> shows the parent directories), it can also be confusing. For example, I want
> to
> save something in my home directory, but I accidentally navigate to the
> Desktop
> directory. I then assume I can just go back to /home/user using the 'trail',
> but this is not the case. Since going back in the trail automatically selects
> the directory that you came from (i.e. going to user from Desktop using the
> trail will result in Desktop being selected), you actually have to go to
> /home
> in order to select /home/user.

That and Comment 8 are now tracked in Bug 679865.


We can keep this open for the first part, which seems more general:

(In reply to Mike Williamson from comment #0)
> I believe that the folder chooser that is used when extracting in
> file-roller, selecting a folder when taking a screenshot, etc. is
> unintuitive. If a folder is selected in the right hand pane, then hitting
> Open will use the selected folder. However, if a folder is not selected,
> then Open will use the current folder. This, to me, appears to be
> unnecessarily confusing behaviour.
Comment 11 Robert Orzanna 2018-02-12 16:14:14 UTC
Hey everyone, 

Coming from [1] and would like to suggest that if you go up the folder hierarchy, then maybe it should unselect any previously selected folder to prevent the case from users accidentally ending up in an unintended subfolder where they don't want to save the file and don't know how to exit again.

I hope I explained it well enough.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=793307#c5
Comment 12 GNOME Infrastructure Team 2018-05-02 14:23:28 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/271.