Objects in 3D or 2D editors should have to be selected before moving

[fire]

Describe the project you are working on:

Non-released project

Describe the problem or limitation you are having in your project:

The user experience of editing 3d objects in the scene is frustrating.

Describe how this feature / enhancement will help you overcome this problem or limitation:

When a developer wants to edit a potted plant in the 3d scene, they will often misclick the ground and move it directly.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Behaviour before:

• Wants to edit the shader of a potted plant in the 3d scene
• Misclicks the ground and moves it directly
• Must reset the ground transform
• Clicks on the potted plant
• Edits shader

Behaviour after:

• Wants to edit the shader of a potted plant in the 3d scene
• Clicks on the ground will select the ground, not moving the ground
• Clicking on the potted plant model will select not move it
• Can now change the shader

Here are some test cases. Please comment if they're in error.

• Given any unselected objects, clicking on one will select it and it will not be moved.
• Given selected objects, clicking on any unselected object will select it and it will not be moved.
• Given selected objects, shift clicking on any unselected object will add to selection and it will not be moved.
• Given one or more selected object, with shift clicking on an selected object will cause all objects to be moved.
• Given any objects and one is selected, clicking on the unselected object will cause it to be selected and not moved.
• Given selected objects, clicking on any selected object will move the group.

Describe implementation detail for your proposal (in code), if possible:

https://github.com/fire/godot/tree/select_usability

A buggy prototype.

Not implemented yet, an editor setting to revert to current behaviour.

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

No, the behaviour of the 3d editor cannot be modified through script.

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

3d editing is a core feature.

[fire]

Here's a video of my prototype:

Video

Flaws in my implementation, there's an off by one in selecting.

Edited:

Shows in 3.2 stable too... So it's not a bug.

Edited:

The gizmos should override the selection hold.

[fire]

Here is the existing behaviour:

https://imgur.com/AVXbu5A

[golddotasksquestions]

Given selected objects, clicking on any selected object will move the group.

I don't know a single usecase where a simple click should move anything in the editor.
Do you mean "Given selected objects, left-click on any selected object + drag will move the group."

Given one or more selected object, with shift clicking on an selected object will cause all objects to be moved.

May I ask what the purpose of this rule would be?
Assuming you meant "Given selected objects, left-click on any selected object + drag will move the group." with the other rule, pressing shift would be of no effect.

I would much rather have:

• Given selected objects, left-click on any selected object + drag will move the group.

and

• Given one or more selected object, with shift left clicking on an selected object will cause the object that is left clicked to be removed from the selection group.

The current implementation is a "universal handler". It allows a much faster workflow in top and side views compared to when you have to switch between tools for selection and movement.
Other software mitigates the problem you are describing by allowing the user to select between two selectors (one universal handler, and one only selector) as well as the ability to lock objects as being unselectable and unmovable. We have neither of those options.
I don't think the solution is to make the editor even slower to work with. I'd much rather we would deal with the actual problem, that is the missing selection/movement lock.

[fire]

How would you solve this?

When a developer wants to edit a potted plant in the 3d scene, they will often click the ground and move it. They would rather edit the shade of the potted plant to be a different colour.

Given selected objects, left-click on any selected object + drag will move the group.

This is the wrong behaviour.

What I did in this prototype is, you must first select the object and then drag on it again to move it.

After an object is selected, you can select more objects. The second click does the transform move.

Have the ability to lock objects as being not selectable and not movable.

This already exists, it's not reliable because of nested scenes.

[fire]

Given one or more selected object, with shift clicking on an selected object will cause all objects to be moved.

Another way of saying this is:

There are two modes.

1. Objects are not selected.
2. Once selected, you can move the object. There is a ray trace to the object and it returns true and shift is not held, moving the mouse will move the object.
3. Once selected, you can move the object. Clicking on an selected object will cause the object that is left clicked to be removed from the selection group.

What you're saying makes sense.

[fire]

Once selected, there is a behaviour where clicking any object will deselect all objects and then pick the current object under the mouse.

With selection and shift, clicking on an additional object will deselect it!? and then the behaviour for moving objects triggers. So it deselects and then moves the other members of the selection group. However you[r] mouse is still at the deselected object's x-y screen position.

I got stuck here. Any suggestions? See the video.

[golddotasksquestions]

Left click select and drag should be left click select and drag. It's like that everywhere with (universal) multi tools.
If we change that behaviour to left click then leftclick again to move, it's again a Godot-unique ideocracy. That's muscle memory people will have to unlearn and relearn just for Godot.

Leftclick select and leftclick select + drag are two different inputs. With one the user wants to only select, with the other the user has made up their mind they also want to move the object (provided they do this with the universal multi tool.

Currently, neither seems to work for me:
https://i.imgur.com/4IrLidk.mp4
In this video I only leftclick and leftclick+drag

I gave up figuring out why and select objects in the scene tree and only move them with the gizmo arrows. Which sucks and is slow as fukc.

[fire]

Here is the comparison in Blender. https://www.youtube.com/watch?v=RWjlA7ggTXg&feature=youtu.be

Notice that Godot Engine matches neither tool.

This patch attempts to implement the [last] tool in the video from Blender. I think [that] tool is the functionality people expect.

[Edited] I posted the wrong video.

[golddotasksquestions]

Myself and many of my colleagues have shied away from using Blender for as long as they could exactly because Blender does many things it's own way. Especially with these basic UX behaviors. Even though blender is free, even though they then have to use expensive proprietary software. Blender is really not the best example.
At least blender has multiple kinds of selectors:

[fire]

I didn't want to record Unity...

Anyways, here's a video of the blender tool. https://youtu.be/kUlF6HkXPus

[fire]

Given the difficulty of changing defaults, I was thinking of adding a "transform" mode button that does this mode.

[Seel]

What about adding a bit of hysteresis. When you click on something you often move the mouse a bit just coincidentally, if those small movements are disregarded for starting movement it might already help a lot.
(So, clicking on something with some small mouse movement = select. Clickling and holding the mouse for longer plus dragging for longer = start moving.)

[jasonhowelldev]

This aggravates me so much. Especially since the tool tip shows that alt drag should move.

So how this should work, is dragging should always box select. Holding alt and dragging should move whatever you were on when started the click on the drag.

[Flavelius]

Still an issue in 3.2.4.rc4 this accidental displacement happens way too often.

[Calinou]

This was implemented by godotengine/godot#49310, closing. The exact implementation is different from the original proposal, but it fulfills the same need (in a way similar to Inkscape and Blender).

[Flavelius]

Does the linked commit prevent unwanted drags? Because rect-select is not possible while dragging implicitly moves an object no matter If it's thresholded.

[Calinou]

Does the linked commit prevent unwanted drags? Because rect-select is not possible while dragging implicitly moves an object no matter If it's thresholded.

It should prevent unwanted drags regardless of the node is previously selected or not.