GNOME Bugzilla – Bug 697101
file browser: can't rename newly created file/folder
Last modified: 2019-03-23 20:33:09 UTC
To see the problem: 1. Start gedit and open the file browser. 2. If you are not looking at a directory where you have write permission, navigate to a directory where you can write and then restart gedit. (This bug only occurs if you have not navigated to a new directory in the current gedit session.) 3. In the file browser, choose New File or New Folder. A new file or folder will be created and highlighted, but it will not be selected for renaming. In fact, if you now press F2 nothing will happen. To rename the file/folder, you must select a different file and then switch back; then you'll be able to press F2 to rename. Normally a newly created file/folder is selected for renaming; that's what should happen in this case.
I still see this in gedit from git master with GTK 3.11.2.
There's a bounty on this bug at Bountysource: https://www.bountysource.com/issues/1331759-file-browser-can-t-rename-newly-created-file-folder On that page a user named Xavier said he started working on a solution on Dec 11. Xavier, are you still working on this? Do you have any progress to report?
Created attachment 267864 [details] [review] Do not grab focus when renaming an item in the file browser
Thanks for the patch. Can you explain (in the commit message) why not grabbing the focus fixes the bug?
@Paolo: Sorry, apparently forgot to add myself to the CC list. Sure, give me a few days, I want to confirm exactly why this is occurring.
So when I took a closer look at this, I found there is likely a deeper issue. I probably don't have the time to figure this out. I believe another individual is claiming to have solved it so I will direct him here.
@Daniel Wyatt, as you have said, I believe I have now solved the issue. Unfortunately, I do not have any idea about how to send a solution. As a matter of fact, there really is a deep issue I couldn't figure out, neither. However, with my solution, the bug cannot be reproduced. Also, I have now detected another bugs within the file browser plugin which I will report them later.
@Hamza: To send a patch, create it using 'git format-patch' and attach it to this bug report. See https://wiki.gnome.org/GnomeLove/SubmittingPatches
Sorry, but my solution is exactly the same solution as @Daniel Wyatt already attached.
This is a problem of GTK. GtkTreeView widget cannot grab the focus using gtk_widget_grab_focus(). Also something wrong is done to the widget in gtk_widget_grab_focus() that causes this bug.
More specifically, GtkTreeView cannot grab focus until the first time it has focus ( by clicking or etc.)
I'm not convinced it's a GTK bug but I really don't know. I likely won't have time to look into this. Here are some things I've observed for anyone else willing to investigate: -The issue is only present before selecting an item in the tree view (you can deselect it after) -Removing the gtk_widget_focus call in gedit_file_browser_view_start_rename call 'fixes' it -Removing the pixbuf cell renderer in gedit_file_browser_view_init also 'fixes' it -cell_data_cb is called many more times when creating a new file _after_ selecting any item in the tree view (that is, when the issue is not present, cell_data_cb is called a lot more)
Created attachment 277448 [details] [review] Proposed patch to start editing the text cell on rename This patch sets the focus cell to the text cell, as it was not possible to start a rename before clicking an item in the tree view because of the focus cell being the icon cell, which can not be edited. After setting the focus cell to the text cell, new file and folder creation starts a rename even before the first tree selection.
Patch updated based on IRC review from Paolo Borelli: * patch looks good * maybe add a small comment? /* grab focus on the text cell which is editable */ or something like that * codestyle nitpick, wrap the line for the second argument Updated patch pushed to both master and 3.12 as requested by Paolo on IRC. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.