GNOME Bugzilla – Bug 326581
New folder loses focus
Last modified: 2006-04-09 15:34:13 UTC
After having created a new folder in Nautilus, the folder list is sorted, causing the new directory to get a new position in the list of folders. Also, the newly created folder loses focus. Instead, the last folder in the list of folders is given focus. This is unwanted behaviour, since a lot of times you want to enter your newly created folder (at least, I do). Thus, Create New Folder -> Naming it -> Enter to confirm -> Enter to enter the newly created folder fails. Suggested behaviour is to let the newly created folder retain focus after placing it at the apropriate position in the list of directories after creation. Other information:
To clarify, this bug exists only in listview, and it happens in any "rename operation", not only in the "new folder" case, and to hit the bug you have to rename to a new name that has different ordering than original, e.g. if you rename "foo.txt" to "foo2.txt" you will not notice the bug, but if you rename it to "zoo.txt" then the next file after "foo.txt" will be selected instead of the new "zoo.txt". That's what I see with current nautilus HEAD.
Created attachment 58910 [details] [review] Patch After rename a file/folder the patch works well if you press ENTER quickly, if you press it *very* quickly it'll throw an error dialog[1], but you close the dialog an press ENTER and now it'll open. So, I think the patch is good for a general use as fixes the bug in most cases (as much as we can). If you wanted to fix the very-quickly case, for what I see, you'll have to do deeper changes to other files apart from fm-list-view.c and don't know if it'll be doable as we depend on the standard gtktreeview behaviour (in contrast with our custom icon view). In concrete, the listview not being as fast as icon view is because a rename in listview translates in "add row with new name + remove row with old name" which takes his time to show up in the gtktreeview, while iconview just sets "editable=false" in the text_entry and it's done. [1] Because the file/folder got renamed but the file_changed handler is not yet executed and so the gtktreeview is still showing the old name and so you're trying to open the file/folder by its old name.
Created attachment 59214 [details] [review] Patch that fixes all cases Well, I took the time to look closer at this and now I have a patch that works 100% so you can press ENTER as fast as you can :). Bug consisted of two issues: - File renamed not being selected (focus). - Dont wait for the rename to end before activating a file being renamed (pressing ENTER very quickly). The patch solves them by doing following: The listview->details->renaming_file variable tracks a rename operation life from when it starts till the new item appears in the gtktreeview (and we selected it) or till rename failed with error[2]. So when ENTER is pressed while a renaming_file is not null we will keep calling ourselves again in 200ms(thanks to a timer) till rename ends (in my tests that happens always after the first 200ms for local locations). I tested the patch in slow ftp folders and works as well as in local locations. I also tested with rename errors. [2] I had to add a new signal RENAME_FAILED to NautilusFile so the list_view is able to know when a rename failed.
Speaking as a user, thank you so much for working on this.
Thanks a lot for your hard work Nelson. As a programmer I supposed this would be an easy fix :) I never worked on Nautilus though, and it seems a lot is going on behind the scene, making it more complicated to fix this one than I thought it would be.
Created attachment 59728 [details] [review] Patch for a second approach to this bug This patch has a different approach[1] where we notify the listview about the rename failed from a callback that we passed to fm_rename_file[1]. After making this patch I particularly prefer the first approach where I used a signal, because here I had to passed to fm_rename_file a GList that had the callback and their arguments (a listview pointer) and the fact that the icon view doesn't passed this makes the patch a bit more ugly as we have to check what arguments the GList has. Anyway both patches work, I'll attach an update of my first patch to also emit the signal on rename cancellation. [1] based on the review on nautilus-list: http://mail.gnome.org/archives/nautilus-list/2006-February/msg00055.html [2] Instead of a signal.
Created attachment 59731 [details] [review] Update of the signal approach patch I forgot to also emit the RENAME_FAILED signal on rename cancel, this patch corrects this. As I said, I think this patch is cleaner and more readable that what I could do in the other patch.
should be fixed in cvs now.
*** Bug 337370 has been marked as a duplicate of this bug. ***
*** Bug 160226 has been marked as a duplicate of this bug. ***