Can't move node inside Viewport

[KoBeWi]

Godot version:
3.0/3.1-dev

Issue description:
When you place node (e.g. Sprite) inside a Viewport, it can't be moved in the editor - you need to manually change position in inspector. While with select tool this is understandable behavior, because your viewport display node (ViewportContainer in my case) is selected instead of sprite, move tool doesn't work either.

Steps to reproduce:

1. Add a ViewportContainer (or any Control node)
2. Add Viewport as a child
3. Add Sprite to the Viewport and make sure it displays
4. Press W to select move tool
5. Try to move the Sprite
6. Spoiler: it won't move

Minimal reproduction project:
Contains aforementioned scene setup.
TestProject.zip

[wangjianpeng]

I still meet this problem , how do you solve it at last ?

[KoBeWi]

I found #17739 and either this one should be closed as duplicate or that one, because has less details.

[fossegutten]

still valid in 3.2.2 betas. Nodes inside another viewport are not selectable. I just select the viewportcontainer when i try to select nodes inside a viewport.

[PrototypeNM1]

For anyone investigating this issue, this behavior was disabled in e997c0d for reasons explained in #1383

[KoBeWi]

Still valid in aed16c8

Unless this is really going to be fixed (see comment above), maybe we should just add a warning somewhere? Otherwise people will keep reporting this or similar issues (e.g. #3572)

[sjharb]

Still valid in aed16c8

Unless this is really going to be fixed (see comment above), maybe we should just add a warning somewhere? Otherwise people will keep reporting this or similar issues (e.g. #3572)

I agree I got stuck on this one today, and since there is no 'info message' or feedback on the screen saying why I cannot move objects even though the 'move' icon in visible and selectable. Either tell the user why 'move' functionality is disabled or just don't allow the user to enter 'move' mode in the editor to make it more clear that it is disabled for this case.

[Nivdc]

Since this behavior is intentional, I'd like to know if there is any other way to efficiently edit nodes within the viewport?

Now I only know to use the Inspector to edit the node's position properties to adjust the layout.
Is there any other better way?

[Blue-Peanuts]

Since this behavior is intentional, I'd like to know if there is any other way to efficiently edit nodes within the viewport?

Now I only know to use the Inspector to edit the node's position properties to adjust the layout. Is there any other better way?

My current work around is to save the children of the SubViewport as a separate scene.

[sjharb]

Since this behavior is intentional, I'd like to know if there is any other way to efficiently edit nodes within the viewport?
Now I only know to use the Inspector to edit the node's position properties to adjust the layout. Is there any other better way?

My current work around is to save the children of the SubViewport as a separate scene.

This is also what I have done to work around this annoyance.

[golddotasksquestions]

@Nivdc

Since this behavior is intentional, I'd like to know if there is any other way to efficiently edit nodes within the viewport?

Editing the children of a subviewport as a separate scene is not always desired, because the user than can't see the context anymore. If for example you want to align the 2D children of a SubViewport with 2D nodes which are siblings of the SubViewportContainer.
So my most common workaround is actually grab all children nodes of the SubViewport and in the scene panel drag them into the parent, edit/move them there, then drag them back to make them children of the SubViewport again.
It's a terribly annoying workaround, but imho the best option still.

[EduardoLemos567]

My opinion is that the users expect a consistent behavior for 3d and 2d when using subviewports. In 3d we can still see and edit objects. My understanding is that the 3d objects and the subviewport all belong to the same 3d world of parents, unless you mark 'own 3d world'. Maybe the solution is just to copy this behavior for the 2d world, if possible.