GNOME Bugzilla – Bug 349502
option to copy full path in "Save AS"/"Open file" dialogs
Last modified: 2011-08-23 22:14:18 UTC
I don't see any option to copy full path of the file in above dialogs. I mean when we have a file open with any application it's very useful when we cold copy the full path and thus we can easy and fast open directory containing this file in any file manager. Such way is very common in Windows, KDE, CDE. In GTK application we can't do it. Other information:
This is at least a problem in GTK 2.8 on X11. The GtkFileChooser (Widget/Dialog) is simply missing an editable location box, which could be used for copying a path as suggested above and for small edits in parts of the path without having to browse up and down in the directory structure. For example it would be nice to change "/usr/share/someapp/dimmer" into "/usr/local/share/someapp/dimmer" simply by typing the extra "/local". As mentioned by yury dubinsky, this behavior is very common in Windows, QT, Motif, etc. I think it was also available in GTK 1. Keyboard navigation in the Open/Save dialog is also very hard. The problem seems to be a combination of too many buttons and layered composition of the widget.
These dialogs indeed will get a very high ranking in the list of dumbest designed dialogs ever. The only reasonably efficient way to work with this dialogs, is to have an other application open, from where you can copy and paste the path into the field for the file name. An application like e. g. xfe, where you have a tree to navigate, usable Bookmarks instead of the imbecile and mostly useless 'Places' ('Orte' in the german translation) list and in particular can edit and copy&paste the path. And if one loves this clickediclackedi path buttons - have a look at xfe: You can have this elements without the price of avoiding functionality. Dumb design is standard in todays software development, but specially this open resp. save dialog is the most annoying piece of software I've ever seen. Other designs might be worse, but open and save dialogs you will need several dozen times a day. Such a central piece of any application should have an at least half way intelligent user interface. It's a shame, that this bug report is nearly five years old, and nothing has changed!
It's easy to add a "Copy file location" command to the context menu in the file chooser. I'll gladly review a patch for this.
Copying is one thing. In a lot of cases, e. g. when a lot of several external shares is mounted in the same root, it's often much simplier and faster to edit the path, than clicking and clicking and clicking... I've mounted several server shares and must save a patch just received by mail into a certain - deep - path on all of this shares. It's a clicking orgy to save first time. Second time, only one or a few characters of the whole path are different. But I must click and click and click back to the root and then click and click and click forward to the new destination. Third time, only one or a few characters of the whole path are different. But I must click and click and click back to the root and then click and click and click forward to the new destination. Forth time... I would write more examples and reasons, why an editable path is a must. But now my must is to go to the doctor's: Repetitive Strain Injury Syndrom caused by saving a few files from thunderbird...
Why "Copy file location" command is not sufficient: People don't copy&paste. Nobody does it. What people do ist to mark a certain information and than to copy&paste. If I want to scp or to clamscan a file just saved - than I need the full path to paste it in xterm. When I want to google the name of a certain subpath or when I want to enter a subpath in a documentation or... - than with the "Copy file location" command I must open a text editor, paste the whole path there, search again for the information I wish, mark, copy, switch to google, paste, close the text editor, answer "Wanna save?"-button... Crazy! There is good reason, to make any text property of a dialog window markable and copyable. You can't imagine, why anybody wants to copy, say, the inscription of an OK-button? Don't imagine, just let the people do! It don't cost you absolutely nothing, but gives the people the freedom, to use the data in the way they want.
Created attachment 192398 [details] [review] Patch to add an copy file selection im popup menu I just wrote this patch, as Frederico told, it's easy to add. I didn't check if has more than one file selected, the get_selected_file always return the last selection. But if necessary, I can work to check if more than one file/directory is selected, then set sensitive to false.
Review of attachment 192398 [details] [review]: Very nice, Arx, thanks! I'd like to put this in gtk+ 3.1 with a few changes: * Please make the label be "Copy file's location". * Make this the first item in the menu, above the "Add to bookmarks" item. * The convention for passing filenames around is to export them as text/uri-list and the various string target types for X selections. You need to do something like GtkTargetList *target_list; GtkTargetEntry *targets; int n_targets; target_list = gtk_target_list_new (NULL, 0); gtk_target_list_add_text_targets (target_list, TEXT); gtk_target_list_add_uri_targets (target_list, URI); targets = gtk_target_table_new_from_list (target_list, &n_targets); gtk_target_list_unref (target_list); gtk_clipboard_set_with_data (clipboard, targets, n_targets, get_func, clear_func, my_data); gtk_target_table_free (targets, n_targets); Before doing that, build the my_data: it's a struct that contains the list of selected GFiles, so you can pass them later to the GtkSelection. Later, your get_func() needs to take that my_data and convert the GFiles to suitable URIs and plain text strings, depending on the "info" parameter - that's the TEXT and URI magic numbers you passed to gtk_target_list_add_*_targets() - just add some magic numbers there in #defines or whatever. You should use gtk_selection_data_set_uris() for the URI case, and gtk_selection_data_set_text() for the other case. For the TEXT case, use g_file_get_parse_name(), not a plain g_file_get_path(), so that we get a proper UTF-8 encoding of the filename. Your clear_func() needs to free my_data and unref its GFiles. Can you please take care of these changes? Thanks!
Created attachment 193271 [details] [review] Patch to add an copy file selection im popup menu with review Hi Federico, The changes you request is done. I test and seems to be fine. regards
Created attachment 194534 [details] [review] bgo349502-filechooser-copy-file-location.patch Thanks for the update! I made a few changes and pushed this to master: - Fix a space in the menu item's title - Sensitize the menu item depending on whether files are selected - Don't use a separator menu item so the commands that operate on the selection stay in the same group. - Support multiple selection properly - Stylistic fixes and a memory leak fix