GNOME Bugzilla – Bug 325150
Save As dialog cannot delete or rename files
Last modified: 2017-01-02 00:38:20 UTC
When saving files, you cannot delete or rename files. This shouldn't normally be a problem, except that you can create new folders to put things into. If you mis-type the name of the folder, you're stuck with this unwanted folder. I would like delete, rename, or both options to be in the context menu. I don't really care where the option is as long as it's doable from the dialog. Other information:
Right now, when creating a new folder, it's too easy to accidentally commit the wrong name - see bug #171416 for that. Do you think you could cook a patch to add the delete/rename functionality? You'd need to do this: 1. Add two new methods in GtkFileSystemIface 2. Implement them in GtkFileSystemUnix 3. Implement them in GtkFileSystemGnomeVFS 3. Contact tml@iki.fi if you don't know how to implement them for GtkFileSystemWin32 4. Add support for this in the GUI.
What if (when running in GNOME, or Windows, or OS X) we had some way of opening a nautilus/explorer/finder window in the same place? A right click rename in the file dialog isn't intrusive, but it's sort of a slippery slope.
i think both are good to have, rename/delete in the context menu, and opening a file manager window. it has always felt oddly asymmetric to me that you can create folders from the save dialog, but there is no way to undo that. rename/delete are not really necessary in the open dialog.
Hello, the missing possibility to rename or delete files/folders in the dialogs is a feature I am missing too. Not only in the save-dialog, also in the open-dialog. Sometimes when I open a file I see unneeded files, or directories, I wanna delete. Or I wanna rename the file before I open it. Otherwise I had to open it, save it as a different file and delete the old one. Or (if renaming were only possible in the save-dialog) opening the save-dialog, renaming it, opening the open-dialog and open the file. Or using nautilus for this little action. A button for starting nautilus in the specified folder is a nice idea, but too heavy in my opinion. Simply renaming or deleting a file/folder in the dialog is much easier for the user. The dialogs have a button to create a folder, because it is faster to use. So I wanna endorse the wish for deleting and renaming files directly in the open/save-dialogs. Greetings Mike
The renaming of the selected file could be bound to F2 as in Nautilus.
Can any of the interested parties write a patch for this? You need to do this: - Extend GtkFileSystem to allow deleting/renaming files. - Implement this in GtkFileSystemUnix and GtkFileSystemGnomeVFS. - Write the GUI to allow those features from the contextual menu. - Allow "F2" to rename files.
I'm going to take another shot at this over the weekend. I know what bogged me down last time was writing the operations, so even if I can't get that I'll put together whatever I have to show.
Created attachment 81482 [details] [review] File chooser with remove file support I got some things done for this over the weekend. I added the GtkFileSystem interface for renaming and removing files. I implemented it for GtkFileSystemUnix, but not VFS yet. The default dialog has been updated to use deleting, but I haven't gotten down renaming yet. The delete should probably also have a confirmation dialog.
Delete and rename operations will increase risk to loss or damage something. My vote is to not implement these features. If delete or rename operation will be implemented, ensure that data will not be lost in any way. Code must try to move file to Trash or make backup copy instead of simple deleting or overwriting it. Please also ensure that these features will not be available in "Open file..." dialog for root user, so user of program run under su or sudo will not be able to alter system files using just "Open file..." dialog. (Yes, I know - it is bad idea to run GUI program under root user and give it to user, but sometimes it is most easy way). It is event better to disable all file system altering operations in "Open file..." dialog and allow them in "Save to file..." dialog only.
Wouldn't it be most consistent with the design goals of the Gnome project to *remove* the "New Folder" feature from the save dialog? After all, it's been said in other bugs (such as http://bugzilla.gnome.org/show_bug.cgi?id=301349), that "we expect our users to use the desktop, and using a "Load file" dialog to manage your files is considered to be horribly wrong." Creating a folder certainly counts as file management, and this bug is an example of how integrating file management into the Open/Save dialog can lead to UI problems.
GTK+ has uses beyond the Gnome project...
The patch is not bad as a starting point, some comments: - To keep compatibility, new functions need to go to the end of GtkFileSystemIface, and the wrapper needs to handle the case that the function could be NULL. - remove/rename_file seems a bit of a misnomer, considering the operation will also work on (empty) directories. - More so for the menu entries. Maybe we should just make them "Remove" and "Rename..." as in the shortcut list ? - Should we bring up a confirmation dialog before deleting files ? The old filesel dialog did that. - Should recursive deletion be possible ? (That would certainly need a confirmation dialog...) - It is a bit odd that the dialog does not allow to operate on multiple files even if multiselection is turned on. Not a problem of this patch though.
If I can give you my opinion, this is not the only feature that is missing... These are really frequent use cases Mr. X is saving/opening a file and this might happen: 1) he needs to rename an existing file because he wants to save the new file with the same name, but does not want to loose the old file (SAVE ONLY) 2) he sees a file, in the current view, that is no more needed, and he wants to delete it 3) he sees a spelling mistake in a filename/dirname 4) he wants to create a directory to save the new file, but he gives the wrong name to it, and wants to rename it (SAVE ONLY) 5) he sees a file that is not in the correct directory 6) he creates a new directory to rearrange the current dir, because he has lots of files that can be grouped now if this happesn, Mr X has to open nautilus to do all these things. This is in my opinion not acceptable.
> If I can give you my opinion, this is not the only feature that is missing... Yes, you right. User needs full blown file manager to be able manage files efficiently. > now if this happens, Mr X has to open nautilus to do all these things. This is in my opinion not acceptable. Why not to add item to the left panel in Open/Save dialog named "Open file manager here" which will open new window of user favorite file manager in current directory? Moreover, why not add ability to place custom items in left panel below "Search" item? IMHO, Open/Save dialog should scan a directory for .desktop files and place all found items below "Search" item. Example: +----------------------------------------- | Locations +-------------------------+ | Search | Open file manager here | Open file with editor | Open file with browser | Open file with viewer | Open file with player | Upload image to Flickr +-------------------------+ | File system locations... | ... BTW: Support for custom actions should be disabled for the root user to minimize security risk. In this way we will be able to solve much more of user typical problems with much less effort and without security risk. Nautilus scripts can be used as example of such system.
I hope that a gtk developer will add his opinion!
> IMHO, Open/Save dialog should scan a directory for .desktop files and place > all found items below "Search" item. Is nautilus built in such a way that some of its components could be pulled out easily and reused in the file save/open box? Surely that would negate the need to remake the wheel on the filechooser? And hey, maybe if it's done that way, if nautilus can open a location on GVFS, any Gnome app can also implement transparency. Or maybe that's just too much :D
*** Bug 301349 has been marked as a duplicate of this bug. ***
*** Bug 516988 has been marked as a duplicate of this bug. ***
I am also a big fan of this addition. Skimming over the code suggests that GtkFileChooser now uses GIO directly, so the wrapping is even less complex. Recursive deletion in my opinion is a must. Maybe there should also be a trash feature consistent with Nautilus, where the direct deletion is only available if /apps/nautilus/preferences/enable_delete is set. However, such recursive file operation require asynchronous file operations as in Nautilus, while currently GtkFileChooserDefault just calls g_file_make_directory(). So the roadmap would be 1) add support for asynchronous file operations to GtkFileChooserDefault, including their cancellation through a dialog, and disabling the list interaction (spinning wheel). For the multi-threading, cf. libnautilus-private/nautilus-file-operations.c, especially how g_io_scheduler_push_job () is used to launch a job from the GUI thread. 2) implement these file operations: new folder, rename, trash, delete 3) integrate a delete/trash visibility functionality that is consistent with Nautilus
I'd rather see a way to open a nautilus window added to the file chooser instead of turning the file chooser into a full file manager.
> I'd rather see a way to open a nautilus window added to the file chooser > instead of turning the file chooser into a full file manager. That sounds like a very nice and simple idea. I also considered proxying the file operations to Nautilus via D-Bus, but discarded it since it can not be used across OS-es.
Created attachment 140400 [details] [review] 0001-Make-path-bar-emit-signal-when-middle-or-right-mouse.patch
Created attachment 140401 [details] [review] 0002-Add-path-bar-helper-for-getting-file-associated-with.patch
Created attachment 140402 [details] [review] 0003-Fix-file-chooser-popup-menu-positioning-function.patch
Created attachment 140403 [details] [review] 0004-Allow-to-open-file-manager-from-file-chooser.patch
I disagree with the idea of limiting it to "open file manager here" as that can be rather inconvenient especially if your directory has many thousands of files. You have to wait a good while for the dialog to load up the file list, then open a file manager and let it load the same list again, then find the file again and rename/delete it. It's quite redundant. I do think adding this button is a good idea, but there should also be the capability to rename and delete files within the dialog. This is one of the major features I miss from Windows. It's quite common, for example I want to save an image, and the name is already in use; comparing the two I decide the existing image should be renamed to something more precise rather than simply appending a number to the perfectly good name I've chosen for the new image. Or when selecting a file to open I might discover that the file's name is misspelled, or especially in Firefox I want to give it a more appropriate name before uploading to a server that will display the name to the public. Also care must be taken to respect user configuration: I use Thunar as my file manager but many programs still use GtkFileChooser, and it'd be a bit of a bother if it opened Nautilus instead, especially since Nautilus likes to take over my desktop.
I also disagree with only adding "open file manager here". That's overkill for the problem - all we need to do is rename/delete, and we don't need to fire up the whole file manager, complete with all the Nautilus extensions or what-have-you, to do that (which will take a measurable amount of time to start, take over the screen and then need me to find the file which I already found once in the dialog) I wish I had this ability every time I decide that the file I'm working on has the wrong name, which happens a lot. For example, if you have a MATLAB function file, the filename must match the function declaration. Therefore, if you change the function name, you have to rename the file. This is a specialised example, but HyperHacker and others have already given a long list of reasons this idea is a good one.
*** Bug 591732 has been marked as a duplicate of this bug. ***
Manny, I would like to have your patches in the file chooser. Can you please create a git branch and put them in there? (They may need a bit of updating for GTK+ 3, etc.).
*** Bug 654311 has been marked as a duplicate of this bug. ***
Almost six years have gone... ...and still no right click with delete and rename. This is the single most annoying missing feature that one encounters on a daily basis when coming from Windows. It affects GNOME, XFCE and LXDE users alike. Leave the filemanager issue for later, just get that right click done. I would like to help with that if possible.
The problem is that Gtk+/Gnome developers think they know better than their users how good UI should look like, despite all of the people complaining the opposite.
(In reply to comment #32) > The problem is that Gtk+/Gnome developers think they know better than their > users how good UI should look like, despite all of the people complaining the > opposite. no, the problem is that the patches are out of date, and somebody has to rework them. take your whining and false accusations elsewhere.
(In reply to comment #33) > (In reply to comment #32) > > The problem is that Gtk+/Gnome developers think they know better than their > > users how good UI should look like, despite all of the people complaining the > > opposite. > > no, the problem is that the patches are out of date, and somebody has to rework > them. take your whining and false accusations elsewhere. Six years have passed since this bug report; that means LXDE project is a younger than this bug. Pointing that out is not whining, it's justified criticism. Noone seems to take notice.
(In reply to comment #34) > Six years have passed since this bug report; that means LXDE project is a > younger than this bug. Pointing that out is not whining, it's justified > criticism. Noone seems to take notice. The only form of criticism that is likely to be noticed in bugzilla comes in the form of a patch.
Can someone please gather the patches and update them for the master branch of GTK+? I'll gladly review them. Whiners will get a swift kick in the ass. Now, pretty please, with sugar on top, update the fucking patches and I'll review them.
In related news, my friend Debian an I switched to XFCE. :-/
(In reply to comment #37) > In related news, my friend Debian an I switched to XFCE. :-/ You were told (though not very kindly) that a patch would be reviewed. Adding noise to bugreports on purpose will lead to nothing more than me banning your account. Obviously criticism is welcome... but stating things that are well known and very obvious (reported date vs current date for any particular bug) is just noise. There are loads and loads of unfixed bugs. Bugzilla easily shows those bugs, shows when they were opened, e.g. https://bugzilla.gnome.org/buglist.cgi?chfieldto=-6y;query_format=advanced;chfield=[Bug%20creation];bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=gtk%2B If you want to discuss, bugmaster@gnome.org. Aside from all that, XFCE is based upon gtk+.
If you ban us all, there won't be any bug reports to worry about. Seriously though, that list looks scary. Why do you think there is so many ancient bugs, while a whole new core user interface is developed? Or should I be sending this to bugmaster@gnome.org? What's that address anyway*? How is it better to send stuff there? *All I was able to find when searching for it was this promising blog post: http://felipec.wordpress.com/2011/09/23/no-gnome-doesnt-want-user-feedback-how-i-argued-in-favor-of-voting-in-bugzilla-and-got-banned-as-a-result/)? P.S. I just noted that blog post is about you :-)
As said, you're adding noise. Use bugmaster@gnome.org and I am ok to argue endlessly. This is not a forum.
*** Bug 706572 has been marked as a duplicate of this bug. ***
Will a rename file/folder feature ever be included in the file chooser dialog?
Hope so. Yesterday was too late. Each time, when I want to attach a file to email in Thunderbird and I find out that the file has a wrong name, I want to do something very ugly. This simple task in KDE file chooser is still impossible in gtk :-( I don't want to open any file manager. I simply want to rename the file. That's all.
Dear developers, Is there some reconsideration of this very enhancing usability request under GTK 3.x? Thankfully for your response, Robert
I might repeat what was already written above, but: Someone with a strong interesting to get this fixed needs to rework the patches above. See comment 36.
Hi Andre, Are contributions through bountysource appreciated and accepted? In that case I will open and back such a request on bountysource. ~ Robert
*** Bug 750217 has been marked as a duplicate of this bug. ***
Here are a couple of patches of a rough implementation of rename and delete (trash, actually, if available). Video of it in action for those who don't want to compile: https://www.youtube.com/watch?v=60kq_H-4uvA This is not a finished patch, it still needs work to stop the file list going haywire when you rename files sometimes. This is my first ever attempt at GTK+, so I'd welcome pointers on how to fix issues! Maybe it also needs some icons or default shortcuts?
Created attachment 306779 [details] [review] This adds basic rename support to the FileChooser
Created attachment 306780 [details] [review] 0002-Add-file-deletion-to-FileChooserWidget.patch
Thanks for the patches!
I had to massage the patches quite a bit to make them apply after recent commits to the file chooser, so I ended up adding the few missing bits (mainly sensitivity and error handling) and pushing them. Thanks again!
Wow, thanks Matthias: redoing those patches for immediate inclusion is really great - I wasn't expecting anyone to do that, I was expecting to have to iterate a few times at least! I will review the differences in the patches and try to learn from them. Thanks again!
Reported 11 years ago, supposedly committed 1 year ago. There is no rename or delete functionality today in Chroimum, GIMP or Inkscape save or open dialogs. Could somebody explain why this is? Thanks!
This change was included in gtk+ 3.x, not in 2.24 which those apps use.