GNOME Bugzilla – Bug 763727
Need an alternative keyboard shortcut to F2 for renaming
Last modified: 2021-06-18 15:52:59 UTC
Various keyboards don't have F keys, especially on newer laptops or compact keyboards that require switching between Fn modes, which is a PITA. It would probably make sense to offer two keyboard shortcuts, F2 and something else involving Ctrl (unfortunately ctrl+R is already taken by "reload")
If you have some suggestion, feel free.
A workaround is described at http://askubuntu.com/questions/696866/keyboard-shortcut-to-rename-file-in-gui-other-than-f2 Summary: add the following line to your ~/.config/nautilus/accels (gtk_accel_path "<Actions>/DirViewActions/Rename" "<Primary>Return") where <Primary>Return stands for "ctrl + Enter" here. Also note that F2 is kinda "universal", so if we were to have another shortcut I hope it's going to be in addition to the existing one, not instead of (and I seem to remember it is rather difficult to have several shortcuts for the same thing).
The workaround explained in comment #2 doesn't work, since we lost the custom shortcuts support in the port to GAction. Having several shorcuts per action is easy, I just wanted to avoid that, but I agree with the issue Jean raised about "F" keys, so if he have a suggestion with some logic behind I would add it.
Hmmm... Windows still uses F2, Mac OS has always used "Enter" (which messes me up quite a bit when I want to open a file and I need to use command+O exclusively), the only other current OS that bothered to look at this question is ChromeOS, where ctrl+Enter is the shortcut to rename files. So maybe having <Primary>Return (ctrl+enter) in Nautilus as the secondary shortcut could make sense if only for consistency with ChromeOS. Otherwise, the only other shortcut that comes to my mind might be ctrl+M (for renaMe).
Operating systems default file browsers are not the only applications that can rename (or edit text) things. When I said "universal", I took the general landscape into account. Notice how I used quotes. The point was it doesn't come out of nowhere. :) I'm not going to list them all here as I don't have a real survey but to name a few: any Microsoft application (Explorer, Visual Studio…), gthumb, LibreOffice Calc, FileZilla. Ctrl + Enter shows properties in several other applications, including Windows explorer, and it used in Nautilus too until it was replaced by ctrl + I (I assume there are valid reasons even if I was not happy with the change) some time ago. Having as a second shortcut for rename seems like a suboptimal choice. I like ctrl + M.
ctrl+M it is then. Marking as newcomers bug (since it cannot be fixed until 3.24 anyway). Search for the action "view.rename". Look for other actions with multiple shortcuts in the app menu -> keyboard shortcuts and then search for their actions and how to set multiple shortcuts for a single action.
Created attachment 342884 [details] [review] In this commit, we added CTRL+m as a shortcut for renaming In order to rename a file, F2 was used as a shortcut. However, some keyboards might not have F's and an extra shortcut was thus needed(one that would preferably be CTRL+m). In order to fix this, I added a "const gchar *rename_fil[]" consisting of F2 and <ctrl>m so that both of these are available for renaming. This change should work in pretty much any case.
Thanks! Can you please create the patch with git format-patch, so your name and email address show up along with your commit message? See https://wiki.gnome.org/Git/Developers#Contributing_patches
(In reply to André Klapper from comment #8) > Thanks! Can you please create the patch with git format-patch, so your name > and email address show up along with your commit message? > See https://wiki.gnome.org/Git/Developers#Contributing_patches But the patch is correct, the author line is there.
Review of attachment 342884 [details] [review]: While the code looks all right to me, the actual commit needs some work (we should have some guidelines in-tree soon-ish). The subject line should include the primary[1] file[2] being modified without the “nautilus-” prefix and without the extension (so, “files-view” in this case), and a short summary of the changes, in present tense (“files-view: add an NSA backdoor”). The commit message should be split, so that each line is of 80 chars or less in length (I personally am fond of 50/72, 50 for subject and 72 for the rest). Now, for the contents of the commit message: don’t explain the code changes, the diff is exactly for that. Try to explain the motivations behind your changes, and steer away from referring to yourself, use a more abstract style. The second line in this case is unnecessary. Not marking the patch as rejected, but it’s not going to be accepted. Sorry. [1] - There might be cases where you modify one file, but other files need to be modified as a consequence as well, in which case the patch can be regarded to modify a single file. [2] - We use “general” for broad changes.
Created attachment 342887 [details] [review] files-view: Add alternative shortcut for renaming files The current shortcut for renaming is F2. However, some keyboards do not have Fn keys. In order to fix this, add Ctrl+M as an alternative shortcut.
(In reply to Ernestas Kulik from comment #10) > Review of attachment 342884 [details] [review] [review]: > > While the code looks all right to me, the actual commit needs some work (we > should have some guidelines in-tree soon-ish). Not really, the commit messages guidelines are GNOME wide. https://wiki.gnome.org/Newcomers/CodeContributionWorkflow#Commit_guidelines > > The subject line should include the primary[1] file[2] being modified > without the “nautilus-” prefix and without the extension (so, “files-view” > in this case), and a short summary of the changes, in present tense > (“files-view: add an NSA backdoor”). > > The commit message should be split, so that each line is of 80 chars or less > in length (I personally am fond of 50/72, 50 for subject and 72 for the > rest). Our guidelines are 50/72, and it has a meaning (old terminals were 72 chars width). > > Now, for the contents of the commit message: don’t explain the code changes, Just clarifying, what Ernestas means here is to not refer to the actual implementation, but rather explain more abstractly the reasoning behind it and the methodology. > the diff is exactly for that. Try to explain the motivations behind your > changes, and steer away from referring to yourself, use a more abstract We use "we" or "it" (as in the patch or nautilus). > style. The second line in this case is unnecessary. > > Not marking the patch as rejected, but it’s not going to be accepted. Sorry. The patch needs work on the commit message, not that it's not going to eventually be accepted. A "reject" it's only when the reasoning behind is wrong. In this case the patch just needs some work, and your next patch with those fix in the commit message will probably be good and merged :)
Review of attachment 342887 [details] [review]: This patch looks good to me, good job!
(In reply to Carlos Soriano from comment #12) > Not really, the commit messages guidelines are GNOME wide. > https://wiki.gnome.org/Newcomers/CodeContributionWorkflow#Commit_guidelines Yeah, my bad there. I keep getting confused about the two. > Our guidelines are 50/72, and it has a meaning (old terminals were 72 chars > width). 80, actually. The IBM punched cards had 80 columns. :p
Attachment 342887 [details] pushed as 3c00fa3 - files-view: Add alternative shortcut for renaming files
The accelerator doesn’t work, since there is already an action for the accelerator and only the first one gets activated.
(In reply to Ernestas Kulik from comment #16) > The accelerator doesn’t work, since there is already an action for the > accelerator and only the first one gets activated. In this case, “the first one” is “view.create-link”.
(In reply to Ernestas Kulik from comment #17) > (In reply to Ernestas Kulik from comment #16) > > The accelerator doesn’t work, since there is already an action for the > > accelerator and only the first one gets activated. > > In this case, “the first one” is “view.create-link”. Toying with the setting that enables the link action results in some interesting brokenness. Disabling the action makes renaming work, but after reenabling it, one can still rename using <control>m, but only until a file has been copied to the clipboard, after which the linking takes place. Reverting the commit and reopening this bug for further discussion.
Is there any option to use one-click rename like Windows?
(In reply to jeyhunn from comment #19) > Is there any option to use one-click rename like Windows? No, editable labels have been removed a long time ago, and, as far as I’m concerned, the concept isn’t planned to be revived.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.