Add a setting to disable Select Mode manipulator gizmo

[Rawalanche]

Describe the project you are working on

General experiments with the engine's UX

Describe the problem or limitation you are having in your project

In Godot, select mode is not a select mode. It's a Move/Rotate/Translate mode which allows for object selection as a side effect.

In pretty much any other software with a 3D viewport, the whole point of select mode is to allow users to reliably select:

1. Without having to anxiously worry about accidentally transforming the selected node in the process of selection
2. Without having huge combined transform gizmo occluding they object they are trying to view

Describe the feature / enhancement and how it helps to overcome the problem or limitation

A simple ability to disable Select Mode transform gizmo in the Editor Settings->Editors->3D. Default value would be enabled so nothing would change on out of the box behavior.

Problems it solves:

1. Select Mode can cause accidental transforms, despite being called "Select Mode", implying it does selection only.
2. User is able to quickly enter select mode anytime they want to view their selected object without manipulator gizmo occluding it. Currently, in Godot 4, there is no straightforward way other than deselecting the object you want to view, but that also clears the object from the Inspector Panel.
3. Manipulator gizmos often overlap with other gizmos, such as CSG primitive dots, so they are in the way of performing reliable editing operation. There's no way to simply quit the manipulator gizmos, as each of the 4 modes (Select, Move, Rotate, Scale) has some.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can not be worked around. It requires engine changes on C++ level.

Is there a reason why this should be core and not an add-on in the asset library?

This is about improving the 3D editor usability out of the box.

[OhiraKyou]

I would prefer it if all of the following were true:

• All modes can select objects.
• There is simply an additional mode for selection only.
• There is a setting that toggles the current behavior of dragging on object beginning an operation (which I would disable to avoid accidents and would recommend be disabled by default).

[Rawalanche]

I would prefer it if all of the following were true:

• All modes can select objects.
• There is simply an additional mode for selection only.
• There is a setting that toggles the current behavior of dragging on object beginning an operation (which I would disable to avoid accidents and would recommend be disabled by default).

1. I 100% agree with you, I also think that it's ridiculous that you can't select in transform modes. But I have experience with Blender community and I know how hostile FOSS communities are to slightest of the UI changes, so I tried to keep my proposal minimalistic, with default behavior not changing.
2. I don't understand what you mean by additional mode for selection only. Maybe you didn't notice because of the ridiculous combined gizmo but Godot actually has select mode. The arrow icon is the select mode:
   So unless I misunderstand, you are implying to have "Select Mode" and then also some "True Select Mode"? Having two select modes doesn't really make sense. It would make more sense for the additional mode to be "Transform Mode" instead, which woud simply display that combined gizmo, reducing the requirement to switch transform tools that often.
3. I think this is one of those nasty things Godot got from Blender. There's nothing dictating that transform tool modes which allow you to transform from anywhere on the screen (not just by clicking on a gizmo handle directly) have to be in conflict with selection. Other game engines and DCCs prove there are elegant ways of doing that, such as MMB drag or modifer key+LMB drag to initiate the transform. But once again, this would probably be way too much of a change to be accepted for FOSS software, which are usually very reluctant to UX improvements.

[OhiraKyou]

I don't understand what you mean by additional mode for selection only.

I Just mean that the current "select" mode isn't actually a select mode; it's an all-in-one transform mode. So, there would be five modes total:

• Transform (all-in-one, including select) - my favorite, because it removes mode micromanagement
• Move (and select)
• Rotate (and select)
• Scale (and select)
• Select (only)

Of course, there could also be a setting to disable selection in modes other than the dedicated select mode (either overall or one toggle per mode). But, I certainly wouldn't disable selection myself or consider the disabled state the default.

I think this is one of those nasty things Godot got from Blender.

Hmm, I haven't seen this in Blender. If it's a thing, I must have long disabled it. In Blender, I use the G ("grab"), R (rotate) and S (scale) hotkeys, along with axes (X, Y, Z, and Shift+X/Y/Z for the opposite plane). Those hotkeys are great, and I wish every 3D environment had them as options (alongside existing gizmos). I frequently press G, R, or S in a scene viewport before remembering that doesn't work.

[Calinou]

I personally like being able to move and rotate nodes with a single mode, but I agree with removing the ability to move/rotate a node immediately after holding down the mouse button to select it. It's almost never something you intentionally do.

Personally, with the G/R/S shortcuts (see below), I don't use the manipulator as much, but it comes in handy to drag a node across a 2D plane.

Regarding the manipulator gizmo being visually obtrusive, we could hide it when the mouse cursor isn't located within the 3D editor viewport. (The orange selection box would remain visible.)

Those hotkeys are great, and I wish every 3D environment had them as options (alongside existing gizmos). I frequently press G, R, or S in a scene viewport before remembering that doesn't work.

These exist in Godot, but aren't bound by default unless godotengine/godot#78148 is merged.

[OhiraKyou]

These exist in Godot

Whoa, that's awesome! Just enabled the shortcuts, and the only thing missing for me is typing in specific offset values after the axis lock shortcuts. Very cool. Thanks for the info.

Also, I suddenly find myself far more conscious of Blender's Z axis being up.

[Nodragem]

Regarding the manipulator gizmo being visually obtrusive,

The main issue is that it prevents from selecting objects behind the gizmo. That's why it is important to me that we can deactivate the gizmo. Or to separate the "all-in-one transform mode" from the "select mode".

Here, the only solution to reliably select the second can is to click away and then select.

[Rawalanche]

When will this be addressed? It's a trivial fix but over a year since it has been reported.

[tetrapod00]

When will this be addressed?

Whenever someone decides to work on it. Changes to Godot are partly driven by where volunteer contributors decide to direct their attention, and partly by what reviewers are able to review and find consensus on. For proposals especially, there is no guarantee that a proposal will ever be implemented, reviewed, and merged.

For whatever reason, no one has chosen to implement the proposal in this issue yet. My guess is that no one has chosen to work on this yet because:

• This is relatively minor, so apparently no one has considered this important enough to work on yet. About 10 👍 in a year indicates to me that this is a desired feature, but not overwhelmingly so. Contributors are just choosing to work on other things first.
• There is not necessarily consensus around what the best solution is, as seen by the discussion in this issue. So as potential contributors are looking for something to work on, they may avoid this because the review process will be more difficult than a straightforward addition of a new feature.

It's a trivial fix

If you think so, and want to contribute a PR for it, feel free to do so. But be aware that the review process might not be straightforward, since reviewers would need to reach some consensus that the solution chosen is the right one. Note that there is some disagreement about the right fix even in this issue.

[Calinou]

The main issue is that it prevents from selecting objects behind the gizmo.

We could support holding down a modifier key like Alt to select objects behind the gizmo. This could also temporarily hide the gizmo while held down.

[Rawalanche]

The main issue is that it prevents from selecting objects behind the gizmo.

We could support holding down a modifier key like Alt to select objects behind the gizmo. This could also temporarily hide the gizmo while held down.

This once again doesn't address the main issue. Godot simply doesn't have a select mode, which is preset in nearly any other mainstream software with an interactive 3D viewport. The whole point of this mode is to explicitly prevent any interaction other than selecting. It's a mode that should allow you to just select entities in the 3D viewport and edit their properties, without possibility of accidentally transforming them.

Aside from the absence of this mode, the second part of the problem is that Godot has a mode which is incorrectly called Select mode while it is in fact not a Select mode.

[ryevdokimov]

We could support holding down a modifier key like Alt to select objects behind the gizmo. This could also temporarily hide the gizmo while held down.

godotengine/godot#87793 did include a shortcut that you can map any key to hide the gizmo.

A pretty simple way combined with the linked PR to maybe achieve the goals of this proposal without significantly changing anything else, is that when the gizmo is hidden, and in Select Mode it disables modifying the transform of the node completely (currently just clicking anywhere on the mesh and dragging will move it). This makes it somewhat more faithful to its name too, although not the default behavior.

Here is a related PR that addresses other accidental transforms: godotengine/godot#87756

[Rawalanche]

I do not understand why is there such an insistence of doing literally anything else than what my post proposes. It's as if FOSS software had some hidden law to avoid good UX. It feels like any open source developer just looks at the most mainstream concept of doing something (left click to select item for example) and goes "That's way too simple and straightforward, we need to do it the FOSS way".

I do not get why godotengine/godot#87756 and godotengine/godot#87793 reference my proposal when they once again have nothing to do with my proposal.

The idea of my proposal is that you press the Select Mode shortcut key and are instantly in a mode where:
You can not accidentally transform
You see no gizmos

And when you press a shortcut key of transform modes, like Move/Rotate/Scale, you are instantly in a mode where:
You can transform things
You can see transform gizmos

---

What my proposal is absolutely !NOT! about is a solution where to achieve select mode, you need to:

1. Press a shortcut to enter it
2. Move your cursor over a viewport menu
3. Click the viewport menu
4. Move a cursor over display gizmo option
5. Click the option to hide gizmo
6. Perform the safe selection

And in order to return to a transform mode, such as move, you need to:

1. Press a shortcut to enter it
2. Move your cursor over a viewport menu
3. Click the viewport menu
4. Move a cursor over display gizmo option
5. Click the option show move gizmo
6. Perform the transform

I am very much looking for one step process when switching between transformation and selection, not 6 step process

There should be no transformation in a mode that is called SELECT mode. If your argument is that you should be able to select and transform at the same time, without having to switch the modes, then answer to that argument is this already implemented PR: godotengine/godot#86804 If you want to be able to select and transform at the same time, there are already transform modes, so you should be in one of them. The whole point of having a mode called Select mode is that I can rely on nothing being transformed by accident, Alt key pressed or not.

---

With the past few patches mentioned, we got Godot bloated with quite a few more checkboxes while the basic UX request was still not addressed. We could have gotten away with not polluting Editor Settings with too much stuff simply by having ability to transform objects by click-dragging anywhere on the object surface available only in transform modes, and having a TRUE select mode. Instead of Alt key defining whether click-drag object surface transform is possible, Transform mode being active would define it. Such behavior would also address godotengine/godot#87608 while not adding UI bloat.

The user who made the aforementioned report themselves says:

So I guess the main question is if there is a way to block Godot from moving 3D objects in Select or any of the Translation Modes if I click/drag the cursor in the scene but not hovering the gizmo?

...literally the same request - to make Select mode actual Select mode. They say nothing about some Alt key shenanigans. Really, why is there some hidden rule to try to work around the request in 100 different ways but avoid just directly implementing the simple request at all costs.

At some point, preferences in software become so granular customizing them is a frustrating task no one wants to do. And what's worse, many of these settings have often wrong defaults.

[Rawalanche]

Oh, I forgot to mention. I use Industry Standard navigation scheme with Godot (for some reason called Maya):

In this mode, Alt+LMB is Viewport Orbit operation, so the proposed Alt key to transform thing would essentially break it.

[ryevdokimov]

What my proposal is absolutely !NOT! about is a solution where to achieve select mode, you need to:

I think you misunderstood my suggestion. If you bind a key to View Transform Gizmo, are already in Select Mode, and have a PR merged that includes code to specifically disable transforms when the gizmo is hidden in that mode, this would be exactly a one step process (Pressing the key bound to View Transform Gizmo, which can be any key you want,)

I actually do agree at least with the statement that it is confusing that the mode is called Select Mode but function more like Unity's Transform Tool. I don't necessarily agree with your suggested implementation in this proposal though. I think having it be an editor setting is as much as a band-aid as anything else. UI/UX is complicated. Unity doesn't have a dedicated select mode that I am aware of, but they mitigate accidental transforms and streamline things by just making all tools select and having none of them transform unless the gizmo is explicitly clicked on, or some other button is pressed, but they also don't have a way to hide to that gizmo without scripting. I try to understand that Godot is also not Unity or other software, and people have been doing things a certain way for a long time and there would need to be a large amount of consensus to change that (which this proposal does not have, hence the conversation).

Here is a video below of me quickly switching on and off the transform gizmo using the shortcut.

2025-01-03.05-20-23.mp4

[Rawalanche]

What my proposal is absolutely !NOT! about is a solution where to achieve select mode, you need to:

I think you misunderstood my suggestion. If you bind a key to View Transform Gizmo, are already in Select Mode, and have a PR merged that includes code to specifically disable transforms when the gizmo is hidden in that mode, this would be exactly a one step process (Pressing the key bound to View Transform Gizmo, which can be any key you want,)

I actually do agree at least with the statement that it is confusing that the mode is called Select Mode but function more like Unity's Transform Tool. I don't necessarily agree with your suggested implementation in this proposal though. I think having it be an editor setting is as much as a band-aid as anything else. UI/UX is complicated. Unity doesn't have a dedicated select mode that I am aware of, but they mitigate accidental transforms and streamline things by just making all tools select and having none of them transform unless the gizmo is explicitly clicked on, or some other button is pressed, but they also don't have a way to hide to that gizmo without scripting. I try to understand that Godot is also not Unity or other software, and people have been doing things a certain way for a long time and there would need to be a large amount of consensus to change that (which this proposal does not have, hence the conversation).

There's absolutely nothing complicated about UI/UX in this case. Unity is not the only reference for this. There's also Unreal, Cryengine and literally every 3D DCC out there (Blender, Maya, 3dsMax, Modo, etc...) On top of that, Unity does have something like a select mode. It's called a Pan tool but it fulfils the same purpose - prevention of accidental transform. It's the mode you can rest in without worrying you will transform something by accident.

Your video still doesn't show solution to the request. To switch between modes I would still have to:

1. Switch from move mode to select mode
2. Press a button to hide the gizmo
3. Switch from select mode to move mode
4. Press a button to show a gizmo

It still:
A. Would not be a select mode
B. Would not be a single action
C. Would not behave like pretty much any other 3D software out there

Pressing a key to hide a gizmo would still not do for following reasons.
I need to track which mode I am in. I want the gizmo always to be on while I am switching between Move, Rotate and Scale gizmos and always be off when I am in the select mode. I don't want to manage this manually, no one should. That's ridiculous, because at that point the Select/Move/Rotate/Scale mode separation loses meaning. I don't ever want to be in a move mode without gizmo displayed, or in select mode with one displayed.

Also, if it's done this way, then the click-drag movement by clicking anywhere on the surface of the object can not be derived from the mode. It should. It should always work in transform modes and never work in Select mode.

You also haven't addressed how your Alt+LMB toggle will work with the Maya viewport navigation mode.

Yes, having a switch for transform Gizmo in Select mode is a bandaid, but the reason the bandaid needs to exist is that "Select Mode Transform Gizmo" is a stupid oxymoron that should never have existed in the first place. Now that it unfortunately exist, there will be minority of the users whom would be very angry if it got completely removed, because they unfortunately got used to it.

There's also sufficient consensus. There's 11 thumbs ups under my original proposal, and 4 under the post that shows the additional problem of the select mode is that we can't perform other action through the drawn gizmos. I went back and re-read the whole conversation and only disagreement about how to be implemented is from you, as opposed to ~15 other people. You are the only one of the idea that it needs to be implemented FOSS way, because simply doing the most straightforward thing people want, request and are used to from pretty much all of the other industry software would be too simple.

Unity doesn't have a dedicated select mode that I am aware of, but they mitigate accidental transforms and streamline things by just making all tools select and having none of them transform unless the gizmo is explicitly clicked on

Reread this, what you wrote, and you will realize you perfectly described what select mode is. If we assume that godotengine/godot#86804 will be implemented, then this toolbar

Will literally serve as the "explicit gizmo selector" where the cursor icon means no gizmo, the move icons means move gizmo, rotate icon means rotate gizmo, and scale icon means scale gizmo. The only difference between modes these icons on the toolbar toggle should be:

1. What type of gizmo is visible (None in Select, Move in Move, Rotate in Rotate, Scale in Scale)
2. What type of action happens if you LMB click-drag on the surface of selected node(s) (Rectangle select in Select, Move in Move, Rotate in Rotate, Scale in Scale)

[ryevdokimov]

There's also sufficient consensus.

Consensus on implementation, of which I seen a few different suggestions here including creating a whole new tool mode exclusively for selection, which goes directly against the original suggestion. I am one of those 11 people who gave a thumbs up to this proposal because I agree this is a problem in general that needs to be discussed.

You are the only one of the idea that it needs to be implemented FOSS way.

I'm not sure what this means. The "FOSS" way is about having discussions and building consensus is my understanding, which is what we're doing, and I think works fine.

Also, if it's done this way, then the click-drag movement by clicking anywhere on the surface of the object can not be derived from the mode.

It would still work this way with my suggestions.

I don't want to manage this manually

Fair enough. Although if my suggestion is implemented this could be quickly modified via an editor plugin (although not ideal, I do understand this, believe me).

To be clear, my suggestion is not meant to invalidate other suggestions. Accidental transforms, the gizmo occluding objects behind it, and the naming confusion are real problems that can be addressed in a few different ways incrementally or all at once, The discussion is not only to come up with ideas on how this should be implemented overall but can provide people with some workarounds while consensus on a particular implementation has been reached, and someone commits to doing the work.

[Nodragem]

The main issue is that it prevents from selecting objects behind the gizmo.

We could support holding down a modifier key like Alt to select objects behind the gizmo. This could also temporarily hide the gizmo while held down.

I think we should avoid using the modifier keys as much as possible, they are likely used for navigation. For instance, people who uses a pen (e.g. artists) likely use the "Emulate 3 Buttons" mode, in which the modifier keys are activating a navigation type (pan, rotate, zoom). This is partly why I contributed to the GridMap editor; it was hardly usable with a pen tablet.

An alternative solution would be to use Q to toggle the gizmo/transform visibility. Basically it would be like having a "select mode" and a "transform mode" both on the Q shortcut and we would toggle between the two by pressing Q.

Consensus on implementation

I don't know how we can judge if there is a consensus? Even if there was 10 persons out of 10 agreeing here, there are thousands of users out there 😅 so there will always be some risk taking; trying something and see if users like it.

For now, I think there are a few options to solve the problem:

1. make the "select mode" so that it only selects. There is no "transform mode" anymore BUT a checkbox in the Editor Preferences allows to revert the "select mode" to what it was before (i.e. a transform mode).
2. make the "select mode" so that it only selects; add a "transform mode" button, which will allow rotate/move/scale
3. pressing Q activates the "transform mode", when in that mode, pressing ALT activates "select mode" (similar to @Calinou suggestion)
4. have a "select mode" and "transform mode" binded to the same button. To press Q toggles between the two modes. Note: if a user goes to another tool/mode, Godot remembers if it was in select or transform mode the next time the user presses Q. Note: we might want a drawer button, so that end users can see in the UI that the "select mode" button is hidding an extra tool. Note: the button display the icon of the current mode.
5. Same as 4. we use Q to toggle between transform and select mode, but there are 2 distinct buttons in the UI so that it is very clear/visible that both modes exist

Solutions 4 or 5 could make everyone happy because the users who like the old behaviour can stay forever in the "transform mode", while the users who like the new behaviour can stay forever in the "select mode". In terms of Solution 4, I am not sure we have ready-to-use drawer buttons in Godot (see below)? and we would have to at least add a sentence in the button's tooltip to explain that to press Q again will toggle mode.

Here is an example of what I mean by drawer buttons:

[Rawalanche]

This is already standardized in so many different apps, there's really no need to reinvent the wheel to come up with inferior solution.
Option 1. That's how it should be done, but in order to preserve existing functionality, there should be option to have combined transform gizmo in the select mode so that people whom have gotten used to this unfortunate design flaw don't lose access to it. My proposal proposes literally just a single checkbox in editor preferences which exactly defines how people prefer to work.
Why would you add a transform button for select.

Option 2. Why would you add transform mode to select mode when Godot literally has 3 separate trasnform modes?

Option 3. That sounds horrible and is not how any reasonable 3D software behaves. It would interfere with Maya navigation mode which uses Alt+LMB for orbit. It would also not satisfy the requirement to have a safe mode where you can NOT accidentally transform. Having to hold Alt key at all times just to prevent accidental transformation is nowhere in the realm of sanity.

Option 4: No one wants to constantly mentally track which mode they are in if it's cycles by same key. What would be benefit over simply having select mode key always be select mode and Move/Rotate/Scale keys be always transform mode? If the main purpose of the request is to avoid accidental transform and then having to undo it, then if I am in move mode, and I press select mode hotkey, I am still not certain I am in select mode. It will be either select or transform mode based on the last cycle state of the select/transform combined mode. So I will still make mistake, still have to undo it, and then press the select mode key again to cycle, and be super careful to not press it again. It does not decrease room for error, it increases it. It does not help user to avoid errors, it punishes user for making them.

Option 5: Same issue as option 4...

I am starting to lose my mind here. Why would you spend time and mental effort to figure even worse solutions? There is dozen+ different 3D apps that use streamlined combination of selection mode and transform modes, and you never see their userbases requesting any change. Here in Godot, we increasingly see userbase requesting a true select mode without any convoluted neckbeard FOSS twist to it.

How could you possibly come with so many different worse ways to do it in contrast to a simple request, which would add one checkbox to 3D Section of Editor preferences, which would default to a state which would not change absolutely anything for existing users, but just merely toggling it would make Godot behavior aligned with most industry 3D software. Why would you try to replace that idea with some crazy mental gymnastics like having Select Mode key cycle modes, having additional transform mode of select mode alongside dedicated transform modes, or turning select mode in another transform mode, which only selects if modifier key is held...?

I swear if this request was about adding a support for left click-drag to select span of text in text/code editor like it happens in nearly every single text editor, word processor or web browser out there, there would be people here arguing that left-click drag should actually scroll the text editor view horizontally and text selection should happen by something like alt+shift+right click drag. In the FOSS world, it feels like people think there's some medal or award for figuring weirdest way to do things.

[ryevdokimov]

I don't know how we can judge if there is a consensus? Even if there was 10 persons out of 10 agreeing here, there are thousands of users out there 😅 so there will always be some risk taking; trying something and see if users like it.

Which I'd say is part of the process. I agree that it can be difficult to judge the "vibes" of what a generally acceptable solution would be. So, in my opinion it's mostly just having the discussion, various people read through the different arguments and then someone being like "Yeah, I'll give this solution a shot and develop it. I can see it having a chance to be approved, merged and liked well enough by most the user base".

Despite Rawalanche's abrasive passionate way of putting things, I do find myself agreeing with the points and arguments he's trying to make, and I am a person who would be interested in implementing some kind of solution to this. I also used to develop in Unity, so I'm trying to put my biases aside.

Yes, having a switch for transform Gizmo in Select mode is a bandaid, but the reason the bandaid needs to exist is that "Select Mode Transform Gizmo" is a stupid oxymoron that should never have existed in the first place. Now that it unfortunately exist, there will be minority of the users whom would be very angry if it got completely removed, because they unfortunately got used to it.

This is the part I'm trying to reconcile. Do we maybe rename the default to just Transform Mode, add the option Rawalanche is suggesting, that converts it to Select Mode with a modified tooltip and all? Do we add a new button entirely (and still rename things?) That is where I am at right now.

[Nodragem]

@Rawalanche I never said I was against your idea; and I updated Option 1 to better represent your idea. Also, I personally don't like the Option 3, but I was trying to make a list of possible solutions. To try to summarise the options in a list is a way to make the conversation progress and help the decision making.

I think it is indeed very important to look at how other softwares solve this problem. If you look at the screenshot of Blender I posted in the previous post, you can see that they have a "select mode", and a "transform mode" is addition to the move mode, rotate mode, and scale mode.

It is important that you notice that the "transform mode" that combines move/rotate/scale is an industry standard, and appears in many 3D softwares:

• Unity: https://docs.unity3d.com/2020.3/Documentation/Manual/PositioningGameObjects.html
• Maya: https://help.autodesk.com/view/MAYAUL/2024/ENU/?guid=GUID-1E70C450-D88F-436D-8B5A-8395FD8B063F
• Zbrush
• Nomad Sculpt
• Blender
• Unreal (but seems to be just rotate/move): https://youtu.be/uuCH5pXEIVc?t=31

It is an useful feature because it allows to place objects more quickly in a level.

As your option (Option 1) is making it difficult to access the transform tool (i.e. combined move/rotate/scale), it does not seem to be the best option we can find yet. Option 2 is basically what is found in Unity and Blender.

Hence, what about:

• Option 2: Q for Select mode, T for Transfrom mode, two different buttons in the toolbar. Note: shortcut T is already taken, so need to revise the shorcut for "Local Space".

[Rawalanche]

You are missing the point of what's being talked about, and what's being requested.

It's not at all about combined/universal transform gizmo existing (which is not an industry standard still, but is very common indeed). It's about the modes. It is an industry standard to have a select (or navigate) mode which guarantees you can not transform your objects by accident when selecting them. The problem of Godot is that it simply has no Select mode, that is it. It has combined transform mode mislabeled as select mode, and it has no true select mode which can prevent accidental transformations.

I am fine with option that adds 5th mode to the toolbar, which will be combined transform gizmo. I simply won't use it, and will only use the dedicated select mode.

The reason I originally wanted to do it as an editor preference is that I've used most industry software, and the combined gizmo was there, but it was more of a gimmick. I never seen anyone actually use it, because it's super easy to accidentally trigger different transform tool since there are 10 of them concentrated in just one displayed gizmo. So I assumed that it is an user preference, where some people use it, while others never want to come in contact with it.

Either way, as long as I can simply press Q key to be in reliable Select Mode, where I can't accidentally transform something by click-dragging and have no gizmo in way of me clicking on nodes and node-specific manipulators, I will be more than happy. I just don't want to have to first do something, like manually disable gizmo display or cycle modes.

I even agree that 5th toolbar button for combined transform is a better solution, but I approached it conservatively since my experience with Blender, (another FOSS project) is that any request that wants to add actual UI element to main, non preference UI will get rejected automatically because "It would add UI clutter".

[Rawalanche]

This is the part I'm trying to reconcile. Do we maybe rename the default to just Transform Mode, add the option Rawalanche is suggesting, that converts it to Select Mode with a modified tooltip and all? Do just add a new button entirely (and still rename things?) That is where I am at right now.

100% fine by me.

[Nodragem]

It's not at all about combined/universal transform gizmo existing (which is not an industry standard still, but is very common indeed). It's about the modes. It is an industry standard to have a select (or navigate) mode which guarantees you can not transform your objects by accident when selecting them. The problem of Godot is that it simply has no Select mode, that is it. It has combined transform mode mislabeled as select mode, and it has no true select mode which can prevent accidental transformations.

I already agreed with this part and I think there is a consensus there. The point needing to be solved is how we do it so that we still have a combined transform gizmo easily accessible. I agree that combined gizmo are sometimes a gimmick, but we can't really remove it now and level design might actually be the one use case for it 😄 !

I even agree that 5th toolbar button for combined transform is a better solution, but I approached it conservatively since my experience with Blender, (another FOSS project) is that any request that wants to add actual UI element to main, non preference UI will get rejected automatically because "It would add UI clutter".

Yes, that's why I suggested Option 4 where Select Mode and Transform mode are the same toggle button (toggled with Q), or using drawer buttons to combine several tools in one button. I still think I will give Option 4 a try if I get some time. The thing is that you don't need to remember in which mode you are: if you never went in Transform mode, you will always be in Select mode; furthermore, if you are in Select Mode, you won't see the gizmo (so it is pretty obvious you can't transform).

Anyway, I guess we are getting to a consensus of trying Option 2 where we split Transform mode and Select mode in 2 buttons, and we see what are the feedback. To be honest, there still seems to be plenty of space in the toolbar for buttons on my screen!

[ryevdokimov]

Created a PR, give it a shot: godotengine/godot#101168

[Rawalanche]

Created a PR, give it a shot: godotengine/godot#101168

I just built godot and tried it, and it works pretty well. Once you can get someone to make a proper icon (I assume there's someone who made the existing ones?), the only issue that will remain is the hotkey. It's usually standard that Q is the select mode hotkey, so the true select tool should be bound to Q. I personally don't care to be honest, because I can always just remap it, but users on average, especially new users will.

Other than that, it's great. It works as expected and makes Godot feel one big step closer to using a normal 3D software. I finally have a simple mode where I can just simply select landscape and objects on it directly in the 3D viewport without any accidental errors:

[ryevdokimov]

Once you can get someone to make a proper icon (I assume there's someone who made the existing ones?)

I believe @MewPurPur was involved with a lot of the icons in Godot. If you're interested and have the time Mew, I'd appreciate the help. Otherwise, someone else will have to volunteer since I don't think Godot has anyone specifically dedicated to making icons.

the only issue that will remain is the hotkey. It's usually standard that Q is the select mode hotkey, so the true select tool should be bound to Q.

I agree, but I think it will technically break compatibility (since people are used to this) and similar things have prevented PRs from being merged: godotengine/godot#78148 (comment)

[MewPurPur]

You haven't given me a lot of guidance and I don't do 3D stuff, so I extrapolated. I guess you want something that looks close to the Generic6DofJoint3D icon? I made this:

<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16"><g stroke-linecap="round" stroke-linejoin="round" stroke-width="2" fill="none" stroke="#e0e0e0"><path d="M3 11l5-2.5 5 2.5"/><g opacity=".8"><path d="M8 2v12"/><path d="M3 6l5 2.5 5-2.5" opacity=".6"/></g></g></svg>

[ryevdokimov]

You haven't given me a lot of guidance and I don't do 3D stuff, so I extrapolated. I guess you want something that looks close to the Generic6DofJoint3D icon? I made this:

Oh sorry, I probably should have provided a bit more context.

This PR: godotengine/godot#101168 is looking to create a dedicated "Select Mode" for 3D that doesn't include the gizmo. I reused the original select mode icon for that, but now we need an icon for the mode that allows you to both translate and rotate objects.

The Generic6DoFJoint3D was total placeholder that I figured was better than nothing when I decided on it.

I was thinking more something that encompasses the shape of the full transform gizmo itself.

Maybe just a quarter of the gizmo like this?

[Nodragem]

I agree, but I think it will technically break compatibility (since people are used to this) and similar things have prevented PRs from being merged: godotengine/godot#78148 (comment)

I don't think it is a problem here. The PR you mention actually changed the rotate shortcut to CTRL+R which breaks the whole point of QWER shortcuts.

As far as I understand, the QWER shortcuts are meant to keep everything useful under the left hand and minimise hand movements. The buttons in the UI and the keyboard shortcuts should follow the same order. ASDF is used as a second row of shortcuts and ZXCV is the third row. Sometimes the first row extends to T (as it is the case here with the Local Space shortcut).

Based on that, the shortcut V does not make sense.

If you keep Q for select mode, it will just be what it was meant to be, so I think it is good. You can probably have the transform mode move to T or A and move its icon to after the scale mode icon (so that the keyboard shortcuts corresponds to the button order ).

[ryevdokimov]

I don't think it is a problem here.

Ehh maybe, maybe not.

The other half of the problem is that Q has been the "transform mode" as it's has been renamed, for so long that it could be confusing to people who have gotten used to it. Since you can rebind anything afterwards, I figured it is the path of least resistance just to get the functionality in the engine for the people who need it. If it does get merged it might be worth a separate proposal and PR.

I agree with your logic, however.

You can probably have the transform mode move to T or A

T is already used by Use Local Space, I wouldn't be against changing the default for the new select to A though.

[Nodragem]

I had to double-check but, at the moment in Godot 4.3, the shortcut Q is linked to the right most UI button (arrow icon) and it is called "Select Mode". So I think we can argue that it was always meant to be a select mode.

We could see this PR as decluttering the Select Mode, and moving the combined transform gizmo to a dedicated Transform mode. Hence, the Select Mode would remain on Q, and the new Transform mode would go to T or A.

I would suggest that you do your PR with the shortcuts you believe are best, then if the reviewer worries about the shortcuts, you can change them to get the PR merged, and open a separate proposal to continue the discussion. This way we save a little bit of time by getting everything reviewed at the same time.