Page MenuHome

Add rename popup in the 3D View to replace the old Item panel
Closed, ResolvedPublic


In 2.79 and earlier, we had a panel inside the sidebar called 'Item'. In here you could rename objects inside the viewport:

Riggers liked to have a fast way to rename things directly in the viewport.

We removed it because it was quite arbitrary and out of place. But when we did that, we thought to add a popup operator to replace it, like so:

To make it fast, the text would ideally be selected when calling this popup, so that users could simply make it appear, then immediately start typing and press Return.

This is similar to the M-key popup for Collections.

We just never got around to adding this. Therefore, this task is here so we don't forget.

The key for doing this hasn't yet been decided.


Differential Revisions
D4559: Convenience renaming popup (T61480)
To Do

Event Timeline

William Reynish (billreynish) triaged this task as Normal priority.

How would the popup be activated? (what key, which menu)

Campbell Barton (campbellbarton) lowered the priority of this task from Normal to Needs Information from User.Feb 13 2019, 2:17 AM

This would indeed be a welcome addition to bring back. Would it also be possible for the pop up to allow renaming of object data as well?

How would the popup be activated? (what key, which menu)

The right click context menu (W for right click select) seems like the perfect place for that, imo.

If we map it to a hotkey, it should be free in Object, Pose and Armature Edit modes.

It could be Alt-N for Name?

In addition we could add in to the menus and contextual menu too.

Operating systems use F2 to enter rename mode on files and folders. Using this key would add to consistency, but means the File Context Menu would need to be mapped to something else.

I also propose having an object type icon next to the name field, as it's currently in 2.79. It makes it easier to recognize (and verify) what one is renaming.

In any case, this is a welcome addition to the rigging workflow.

macOS uses return key to rename - F2 is not actually used universally. It would be best to perhaps leave this unmapped or choose a blender specific key for a popup. Using F2 (windows), return (macOS), ???? (Linux) on selected items in Outliner, Collections and other lists would be very welcome as that would mimic the OS - rename a selected item. Using such a key to invoke a popup would not feel at all natural.

@Matjaž Lamut (lamoot) Good point, updated above.

@Andrei Nadin (AnadinX) Yes, it's actually curious that we don't use the Return key

+1 for return key (and i've never used mac...). In windows, After effects uses it that way and it works well, and it's a prominent key we're not currently using.

Looking ahead how might this change or be extended in the future?

  • Would this be extended to include object data name too? Other names?
  • Are there other things that would be useful to include here? (batch renaming the entire selection for example).

Should this be a quick meta-data editor? or a kind of context menu for properties instead of operators?

Or is this something we restrict to naming and any patches that add other abilities wont be accepted.

There are times the return key is used to execute an action in a mode - eg, you setup a curve path in sculpt mode then press enter to execute it.

With the tool system - tool authors may want to setup data with a tool then press enter to execute it (image editors often do this with the crop tool for eg).
I think this makes more sense as a typical use case for the return key so binding it to a popup seems a bit odd.

I'd rather reserve the return key for tools (not just use it because it happens to be free in most cases).

Suggest to replace the current F2 file menu with this renaming popup.
Then we can use F2 globally for renaming (sequence & nla strips, objects, bones & nodes - without it conflicting with modes/tools.

While the F2 file menu is handy, overall this may be more useful for renaming.

@Pablo Vazquez (pablovazquez), IIRC you were using F-Keys for open/save - what do you think?

I don't have a strong opinion re the hotkey. Someone suggested Return, which is used in some apps, and in Blender it's basically free, so it seemed like an obvious candidate.

But the main thing is the operator, not so much the specific hotkey.

As for renaming other data: We could add that, sure. But previously we only had a panel to rename objects and bones, so I think that's fine as a start.

When one is making an effort to rename things and keep a scene tidy it is a frequent action to rename both the object and the data at the same time so having both in the same dialog would definitely save quite some clicking around for two very related actions.

As a bonus batch renaming and making the object data dropdown picker also available in the object data name box would be a very welcome addition.

Although renaming datablocks is very useful in the 3D view Enter seems like a prime key way too important key to waste here. It is also often associated to confirming or concluding actions which can cause confusing or conflicts.
F2 like Campbell suggested seems a lot more adequate, while also matching renaming actions in file browsers and other applications.

As a side note, in 2.79 I have currently mapped both my Enter keys (regular and Numpad) to screen.repeat_last, which is a very convenient way to repeat the last action. When duplicating an object it quickly creates an "array"; or after moving an object it "nudges" by increments.

Inspiration: Wrote a very similar operator long time ago: based on a question on stackexchange to rename all objects (and their datablocks) within the selection via Ctrl+R hotkey which fits pretty well and is easy to use. Cheers!

While the F2 file menu is handy, overall this may be more useful for renaming.

I agree with using F2 for initiation of the rename panel. F2 for file browser don’t really have a meaningful use as far as I know.

But also, Return key is used in many modal tools, but since it is consumed by the modal process, it shouldn’t really affect initiation of other functions outside of those modal processes.

I don’t think anyone would want to rename things during modal anyway, unless a modal tool is designed to rename things.

F2 is very user-friendly for Windows users while Return key is user-friendly for Mac users.

We could use both. Renaming multiple things without the need to individually edit them for perfection is going to be a tricky implementation, so leave it for external plugins I guess?

While there are some exceptions Blender mostly doesn't attempt to follow key bindings for the platform (it gets far too complicated).
Even in this case the exceptions are to add keys, not swap them around.

My concern about tools loosing the ability to easily execute an action which is built from multiple operations remains.

Submitted D4559

Can we put the file menu on F5, F6, F7 or F8? I think we still need a quick shortcut for link/append at least.

We could but there was a plan to keep this middle block free for people to bind their own keys.

Suggest this:

  • F4 opens file context menu (as F2 did).
  • Add Preferences (So F4, PKey still opens preferences).
  • Window context menu is a submenu.

    1diff --git a/release/scripts/presets/keyconfig/keymap_data/ b/release/scripts/presets/keyconfig/keymap_data/
    2index 6fffad012df..ce94608cad6 100644
    3--- a/release/scripts/presets/keyconfig/keymap_data/
    4+++ b/release/scripts/presets/keyconfig/keymap_data/
    5@@ -349,7 +349,7 @@ def km_window(params):
    6 ("wm.doc_view_manual_ui_context", {"type": 'F1', "value": 'PRESS'}, None),
    7 op_panel("TOPBAR_PT_name", {"type": 'F2', "value": 'PRESS'}, [("keep_open", False)]),
    8 ("wm.search_menu", {"type": 'F3', "value": 'PRESS'}, None),
    9- op_menu("TOPBAR_MT_window_context_menu", {"type": 'F4', "value": 'PRESS'}),
    10+ op_menu("TOPBAR_MT_file_context_menu", {"type": 'F4', "value": 'PRESS'}),
    11 ])
    13 if params.spacebar_action == 'TOOL':
    14diff --git a/release/scripts/startup/bl_ui/ b/release/scripts/startup/bl_ui/
    15index 0277f6fe129..019757d2e5f 100644
    16--- a/release/scripts/startup/bl_ui/
    17+++ b/release/scripts/startup/bl_ui/
    18@@ -962,6 +962,14 @@ class TOPBAR_MT_file_context_menu(Menu):
    19"TOPBAR_MT_file_import", icon='IMPORT')
    20"TOPBAR_MT_file_export", icon='EXPORT')
    22+ layout.separator()
    24+"TOPBAR_MT_window_context_menu", text="Window", icon='WINDOW')
    26+ layout.separator()
    28+ layout.operator("screen.userpref_show", text="Preferences...", icon='PREFERENCES')
    31 class TOPBAR_MT_window_context_menu(Menu):
    32 bl_label = "Window Context Menu"
    33@@ -987,10 +995,6 @@ class TOPBAR_MT_window_context_menu(Menu):
    35 layout.operator("wm.window_fullscreen_toggle", icon='FULLSCREEN_ENTER')
    37- layout.separator()
    39- layout.operator("screen.userpref_show", text="Preferences...", icon='PREFERENCES')
    42 class TOPBAR_MT_workspace_menu(Menu):
    43 bl_label = "Workspace"

Just another nudge to say, if we are having trouble fitting it onto the F-keys, I’ve used it with Return, it it seems to work nicely this way.

Return is very macOS friendly that has my vote :)

Suggest this:

  • F4 opens file context menu (as F2 did).
  • Add Preferences (So F4, PKey still opens preferences).
  • Window context menu is a submenu.

+1. Sounds like a good compromise. So far all these months using 2.80 I've never used the F4 menu for other than Preferences actually.

I have seen in the Node Editor that you change the name of the Node, not the label. It's very strange to press F2 type something, press enter, and nothing change. I know the top of the Node box is the label, but for new users this looks a bug.

The question is, what we need in Node editor change the name or what we really want is change the label... how many times have you changed the Node name in 2.79..I always changed the label.

My proposal is to replace F2 in Node Editor to change label, not name.

diff --git a/release/scripts/startup/bl_ui/ b/release/scripts/startup/bl_ui/
index 7b9b324066a..3b84a789c95 100644
--- a/release/scripts/startup/bl_ui/
+++ b/release/scripts/startup/bl_ui/
@@ -1088,7 +1088,7 @@ class TOPBAR_PT_name(Panel):
             item = context.active_node
             if item:
                 row = row_with_icon(layout, 'NODE')
-                row.prop(item, "name", text="")
+                row.prop(item, "label", text="")
                 found = True
             if mode == 'POSE' or (mode == 'WEIGHT_PAINT' and context.pose_object):

This was something that arose in this week @Pablo Vazquez (pablovazquez) live stream.

@Antonio Vazquez (antoniov)
The fact that the 'name' and 'label' are different seems just fundamentally confusing.

But yes; I guess it could change the label instead, as a solution to this issue.

@Brecht Van Lommel (brecht) Any idea why we have both, separately? Is there a use-case for that?

@William Reynish (billreynish) Yes, I know...but I think we must do something here, now F2 is not useful as is. I only wanted to bring the topic to discuss.

I don't know the historical reasons for it, we don't do this for anything else in Blender. Fixing this is rather complicated as it would require complicated version patching to preserve animation and drivers.

Making rename affect labels seems reasonable to me though.

Maybe it's an stupid idea, but we could trigger in RNA an automatic update of the label when the name changes.

@Antonio Vazquez (antoniov) @Brecht Van Lommel (brecht)

Sure, let's make it change the label instead. It's what you see anyway.

I will wait for @Campbell Barton (campbellbarton) opinion before commit the change...maybe we are missing something.

One reason why we have both name and label appears to be that the name is always unique, but the label is not. I guess the name can be useful for referencing from a script or driver. So it's probably a bigger topic.

If we keep both, we could rename them to something like Label and Unique ID perhaps. This would at least make the difference clearer.

For now, making Rename change the label seems like a good improvement regardless.

I only see a small problem. The first time you press F2, the label field is empty.

@Antonio Vazquez (antoniov) perhaps it would be nice if the Label field was already set to match the name of the node type. In fact, that's already the case for the title in the nodes themselves.

I know how initialize old files, but I don't know where is the code to create new nodes to initialize the label.

This is the diff so far: D4631