GNOME Bugzilla – Bug 150951
collapsed save dialog needs to indicate filesystem as well as folder
Last modified: 2009-07-15 23:19:10 UTC
In the "collapsed" view of the save dialog, if the "Save in folder" popup shows a folder rather than just "Home", etc., then it needs to indicate what filesystem that folder is on, since the folder name itself may not be unique. Eg, I have a "tmp" folder in my homedir in addition to the "tmp" folder under Filesystem, and I use both. If I see "Save in folder: tmp" in the dialog, I have to expand the dialog to the full form to figure out which tmp folder it's talking about. A more end-user-ish use case would be someone saving files to an external zip drive / firewire hard disk / usb flash memory card, which mirrors the layout of his homedir (and thus has the same directory names)
Good idea. Right now we display [*] Folder name where "[*]" is the folder's icon. Would the following work? [*] Folder name ([*] filesystem)
Yes. (Or maybe "on [*] filesystem" or "in [*] filesystem"?) The same issue applies to folders added to the bookmarks list too.
I think for bookmarks, tooltips with the full path may be a better way to solve this - depends on tooltips support for the tree view though...
There's a more general problem here, which is that the complete path is often very hard to discover. For example, I have several file hierarchies on my system that have many "leaf node" directories with a common name. Common cases for me are "src", "test", "tmp". Other kinds of users might have other kinds of names. The "save in folder" button is displaying an abbreviation of a complete path name---it is hinding some information from the user. Obviously, this hiding is intentional. But as a design principle, it seems to me that the interface should 1) Make it obvious that some information is being hidden 2) Make it easy to discover the missing information On point (1), the current behavior might be fine. On point (2), if clicking on the button displayed entries for all parents in the path, then that might work fine. Instead, what I currently get if I click on the button is a list of "shortcuts", (some hard-coded and some manually created). As is, here is the experience I had today when faced with an ambiguous name ("tmp") in "save in folder: 1) Think, "Is that /tmp or ~/tmp? I need to find out." 2) Click on the button, look through the list, figure out what it was, and realize the information isn't there. 3) Look for something else in the UI that might give the information. 4) Click on "browse for other folders". 5) Look around at new stuff that appeared, and find the information still isn't there. [At this point, a perhaps separate issue is involved. If the file dialog were big enough the information would be there.---Oh it looks like there is a separate bug---the first time I open "browse" the dialog stays the same too-small size. But if I collapse and open it again it actually grows. I'm not sure if that is application-specific (firefox in this case) or not. Let me know if I should file a separate bug for that.] 6) Given the too-small dialog, I could still see only one element of the pathname, so I had to click the leftward-pointing triangle several times in order to discover what directory the dialog was pointing to in the first place.
Note that the save dialogue populates the drop-down with the bookmark label. So you can (and maybe should) rename the bookmarks yourself (right-click on the bookmark and select "Rename..."). For the default, gtk_file_system_get_bookmark_label() implementations should be checked.
Actually, it's in shortcuts_insert_path(), the code looks like: label_copy = g_strdup (gtk_file_info_get_display_name (info)); gtk_file_info_free (info); We should probably have something a bit more sophisticated, that will make a difference between files on different "filesystems"/paths. For example a shortcut for ~/tmp would be "tmp on <username>" or "tmp on Home", and /tmp would be "tmp on Filesystem"
Does anyone care to cook a patch to find the deepest non-leaf path that discriminates between two bookmarks with the same display name? E.g. if you have /foo/bar/baz and /foo/beep/baz, show the bookmarks as "bar/baz" and "beep/baz", respectively. [If you have /foo/bar/baz and /beep/bar/baz, show "/foo/bar/baz" and "/beep/bar/baz"]
(In reply to comment #7) > Does anyone care to cook a patch to find the deepest non-leaf path that > discriminates between two bookmarks with the same display name? That sounds like the perfect plan for the bookmarks. I've got emacs doing the same thing[*] for making buffer names unique, and it is quite delightful. As for the "save in folder" ambiguity, I said before: > if clicking on > the button displayed entries for all parents in the path, then that might work > fine. And I just noticed now that this is precisely the behavior that nautilus provides in a button with the exact same decorations down at the lower-left. So there is already some precedent (and code) for this behavior in GNOME. -Carl [*] For anyone interested, the emacs incantantion to get this behavior is: (require 'uniquify) (setq uniquify-after-kill-buffer-p t) (setq uniquify-buffer-name-style 'post-forward-angle-brackets)
It seems that #3 has been implemented. This seems to be a clean, unobtrusive solution. Can this be closed?
The original bug report was about the "Save in folder" pop-up menu, which is still ambiguous and tooltipless.
No longer...