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 325150 - Save As dialog cannot delete or rename files
Save As dialog cannot delete or rename files
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.8.x
Other All
: Normal enhancement
: Medium API
Assigned To: gtk-bugs
Federico Mena Quintero
: 301349 516988 591732 654311 706572 750217 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-28 15:21 UTC by Andrew Sayman
Modified: 2017-01-02 00:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
File chooser with remove file support (18.45 KB, patch)
2007-01-30 00:35 UTC, Andrew Sayman
needs-work Details | Review
0001-Make-path-bar-emit-signal-when-middle-or-right-mouse.patch (3.88 KB, patch)
2009-08-11 00:26 UTC, Christian Neumair
none Details | Review
0002-Add-path-bar-helper-for-getting-file-associated-with.patch (1.69 KB, patch)
2009-08-11 00:27 UTC, Christian Neumair
none Details | Review
0003-Fix-file-chooser-popup-menu-positioning-function.patch (3.06 KB, patch)
2009-08-11 00:27 UTC, Christian Neumair
none Details | Review
0004-Allow-to-open-file-manager-from-file-chooser.patch (16.00 KB, patch)
2009-08-11 00:28 UTC, Christian Neumair
none Details | Review
This adds basic rename support to the FileChooser (15.50 KB, patch)
2015-07-03 21:22 UTC, John Beard
none Details | Review
0002-Add-file-deletion-to-FileChooserWidget.patch (7.05 KB, patch)
2015-07-03 21:22 UTC, John Beard
none Details | Review

Description Andrew Sayman 2005-12-28 15:21:41 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:
Comment 1 Federico Mena Quintero 2005-12-29 02:10:40 UTC
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.
Comment 2 Owen Taylor 2005-12-29 16:11:59 UTC
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.
Comment 3 Matthias Clasen 2005-12-29 18:22:38 UTC
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.
Comment 4 Michael Gebhart 2006-09-06 21:20:59 UTC
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
Comment 5 Jiří Pejchal 2006-09-15 20:35:27 UTC
The renaming of the selected file could be bound to F2 as in Nautilus.
Comment 6 Federico Mena Quintero 2007-01-25 16:52:54 UTC
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.
Comment 7 Andrew Sayman 2007-01-25 23:09:37 UTC
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.
Comment 8 Andrew Sayman 2007-01-30 00:35:31 UTC
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.
Comment 9 Volodymyr M. Lisivka 2007-02-19 15:24:18 UTC
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.
Comment 10 Alex G. 2007-03-14 20:38:16 UTC
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.
Comment 11 Matthias Clasen 2007-03-14 20:47:55 UTC
GTK+ has uses beyond the Gnome project...
Comment 12 Matthias Clasen 2007-03-14 22:26:15 UTC
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.
Comment 13 Nicolò Chieffo 2007-09-23 20:40:36 UTC
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.
Comment 14 Volodymyr M. Lisivka 2007-09-24 11:09:21 UTC
> 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.
Comment 15 Nicolò Chieffo 2007-09-25 12:29:22 UTC
I hope that a gtk developer will add his opinion!
Comment 16 Nick G 2007-09-28 11:10:51 UTC
> 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
Comment 17 Christian Persch 2007-09-29 10:21:50 UTC
*** Bug 301349 has been marked as a duplicate of this bug. ***
Comment 18 Matthias Clasen 2009-01-30 19:15:21 UTC
*** Bug 516988 has been marked as a duplicate of this bug. ***
Comment 19 Christian Neumair 2009-08-09 13:13:23 UTC
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
Comment 20 Matthias Clasen 2009-08-10 05:01:37 UTC
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.
Comment 21 Christian Neumair 2009-08-10 07:20:02 UTC
> 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.
Comment 22 Christian Neumair 2009-08-11 00:26:51 UTC
Created attachment 140400 [details] [review]
0001-Make-path-bar-emit-signal-when-middle-or-right-mouse.patch
Comment 23 Christian Neumair 2009-08-11 00:27:20 UTC
Created attachment 140401 [details] [review]
0002-Add-path-bar-helper-for-getting-file-associated-with.patch
Comment 24 Christian Neumair 2009-08-11 00:27:50 UTC
Created attachment 140402 [details] [review]
0003-Fix-file-chooser-popup-menu-positioning-function.patch
Comment 25 Christian Neumair 2009-08-11 00:28:17 UTC
Created attachment 140403 [details] [review]
0004-Allow-to-open-file-manager-from-file-chooser.patch
Comment 26 HyperHacker 2009-12-23 01:43:41 UTC
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.
Comment 27 inductiveload 2010-09-13 05:10:15 UTC
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.
Comment 28 Federico Mena Quintero 2010-09-13 16:31:23 UTC
*** Bug 591732 has been marked as a duplicate of this bug. ***
Comment 29 Federico Mena Quintero 2010-09-13 16:37:30 UTC
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.).
Comment 30 Cosimo Cecchi 2011-08-02 08:12:24 UTC
*** Bug 654311 has been marked as a duplicate of this bug. ***
Comment 31 Serge Stroobandt 2011-12-04 11:58:26 UTC
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.
Comment 32 Václav Zeman 2011-12-04 13:37:58 UTC
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.
Comment 33 Emmanuele Bassi (:ebassi) 2011-12-04 13:43:47 UTC
(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.
Comment 34 paxcoder 2011-12-04 15:43:21 UTC
(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.
Comment 35 Matthias Clasen 2011-12-05 13:27:34 UTC
(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.
Comment 36 Federico Mena Quintero 2011-12-05 14:43:17 UTC
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.
Comment 37 paxcoder 2012-09-01 03:13:16 UTC
In related news, my friend Debian an I switched to XFCE. :-/
Comment 38 Olav Vitters 2012-09-02 13:49:00 UTC
(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+.
Comment 39 paxcoder 2012-09-02 18:41:43 UTC
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 :-)
Comment 40 Olav Vitters 2012-09-03 13:52:57 UTC
As said, you're adding noise. Use bugmaster@gnome.org and I am ok to argue endlessly. This is not a forum.
Comment 41 Federico Mena Quintero 2013-08-22 16:33:25 UTC
*** Bug 706572 has been marked as a duplicate of this bug. ***
Comment 42 Daniel Preston 2014-03-19 13:31:43 UTC
Will a rename file/folder feature ever be included in the file chooser dialog?
Comment 43 Marián Kyral 2014-03-23 20:41:28 UTC
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.
Comment 44 Robert Orzanna 2015-01-12 20:01:34 UTC
Dear developers,

Is there some reconsideration of this very enhancing usability request under GTK 3.x?

Thankfully for your response,

Robert
Comment 45 André Klapper 2015-01-12 21:59:02 UTC
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.
Comment 46 Robert Orzanna 2015-01-12 22:40:04 UTC
Hi Andre,

Are contributions through bountysource appreciated and accepted?

In that case I will open and back such a request on bountysource.

~ Robert
Comment 47 Emmanuele Bassi (:ebassi) 2015-06-01 14:32:19 UTC
*** Bug 750217 has been marked as a duplicate of this bug. ***
Comment 48 John Beard 2015-07-03 21:21:08 UTC
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?
Comment 49 John Beard 2015-07-03 21:22:11 UTC
Created attachment 306779 [details] [review]
This adds basic rename support to the FileChooser
Comment 50 John Beard 2015-07-03 21:22:55 UTC
Created attachment 306780 [details] [review]
0002-Add-file-deletion-to-FileChooserWidget.patch
Comment 51 Matthias Clasen 2015-07-04 06:00:10 UTC
Thanks for the patches!
Comment 52 Matthias Clasen 2015-07-05 03:48:21 UTC
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!
Comment 53 John Beard 2015-07-06 08:58:39 UTC
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!
Comment 54 Iwan Gabovitch 2016-12-31 03:16:21 UTC
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!
Comment 55 Carlos Garnacho 2017-01-02 00:38:20 UTC
This change was included in gtk+ 3.x, not in 2.24 which those apps use.