"Object Modes" is a misleading terminology and inconsistently used

This an easy misunderstanding to have because the “Transfer Mode” operator was first added in 2.93 exclusively for Sculpt Mode with the D hotkey: Sculpt - Blender Developer Documentation

Then one release later it was upgraded in 3.0 to support all interaction modes and the hotkey was changed to Alt Q to avoid hotkey clashes in the other interaction modes: Sculpt - Blender Developer Documentation

While I like the name interaction mode, I think the whole “mode” naming is kinda weird and unintuitive (for beginners especially).

  • Basically each Mode gives you a set of tools for a different application.
    I suggest naming it “Tools” instead.

  • Also, the name “object mode” (or tools) doesn’t make any sense (in my opinion).
    Imagen, you know nothing about blender, and someone told you there are things called modes, which basically give you sets of tools for the task, and there is a mode that is called object mode. What does that mean? What tools does this mode include? Also, there are “Object Modes” and “Object Mode,” where one means all the given modes on the object and the other means “Object Mode”.
    I suggest changing the name to “Transform Mode” (“Transform Tools” is more intuitive, in my opinion).
    What can you do in Transform mode (or with the Transform tools)? Well, you can Transform the object… (like what you can do in object mode now…).
    I added the two options:
    editors_3dview_Transform Tools_menu
    editors_3dview_Transform MODE_menu

I don’t really mind the idea of changing “Object Mode” to “Transform Mode”, but transforming objects is not the only thing you do in Object Mode. You also transform components in Edit mode, so I don’t think “Transform Mode” ends up being a more appropriate name when you consider those aspects.

It’s also not appropriate to rename these from “Modes” to “Tools”. While it may be true that the first thing the user notices is that a different set of tools becomes available when switching modes. This is far from the only thing that changes. The entire representation of the data in memory changes, for instance, the mesh data gets converted into the bmesh representation in Edit mode. This means the types of things you can do from a Python scripting perspective, or a rendering perspective, are entirely different in each mode. It’s not just a different set of tools.


Mode is a perfectly fine, and appropriate word for the menus. For beginners that face issue with this, they need to learn some general DCC nomenclature.


Well I guess that the confusion in understanding my topic definitely highlights how not having precise terminology really hurts any discussion. At least one person got what I was aiming at:

The one and only Object Mode.

The “Object Mode” (singular). With this icon:

In which you interact with objects on the object-level. I think its name is correct and there’s no much debate to happen there. “Transformation” isn’t specific to objects.

All the “modes” (plural)

But, what do we all these “things” that we pick in “that popover of things just after the viewport’s popover to pick an editor” and dictate on what data you interact and which tools you get to do so:

Right now, depending on where you look in the UI or documentation, it can be “mode” or “object modeS” (sometimes plural sometimes singular as the above picture, just to add to the confusion :wink: ) or “interaction mode”.

I think we need to pick one distinctive name and stick to it as much as possible in the UI.

  • Modes is too generic alone. It kinda works in the sense that it’s vague enough to fit everything, but it prevents us from being specific, and forces us to use circumlocutions like we do in this whole discussion to specify about which kind of modes we are talking about. We don’t have this issue about the “modes” in the outliner, because they do have a specific name: “Display Modes”:


  • Replacing every mention of “mode” by “tool” doesn’t really make sense to me, as these things are not just a toolset, but also what level of data block you are working on, with all the UI and under-the-hood implications.

  • “Interaction mode” sounds clear to me. These are modes that dictate what we interact with, and how.

After thought

I notice two additional things:

1. Do we need to include the word “mode” in every “Interaction mode”?

I don’t think there are many other places that do this. The Editors popover does have a few ones named editor. But the outliner’s display modes doesn’t have “mode” writen at every mode entry:


Hence, perhaps we could do the same with “Interaction Modes”:


Although that does mean we only see the name of the interaction mode when the menu is closed. Perhaps that would make some people not sure of the meaning? But again, perhaps showing the name here isn’t as needed, much like other menus like the Editor one only shows an icon.

Examples: Transform Orientation popover doesn’t repeat “orientation” at every orientation name available. And the Transform Pivot Point menu next to it have a mix of with and without “point” in the pivot point names, but it shows only an icon with no name in the header.


If any of these situations are clearly giving better results than the others, then maybe a bit of unification could be done.

2. Menu Header

Several popovers (outliner’s display mode, editors, Transform orientation, etc) have a header with a title that tells the popover’s content. Why not in the Interaction Modes popover too?


I will stop the inconsistency hunt there because it’s a rabbit hole i’m already spending more time than i should. x)


I meant to mention this! This menu is weirdly inconsistent, I agree, let’s do this simple change (It’s my OCD speaking if you were wondering).


This entire thread is the definition of looking for a problem. “Mode,” is a standardized, easy to understand word. Everything else makes sense in context as it is viewed/operated upon per datablock. I don’t get the point of this discussion.