Godot: root node changing / moving / removing needs better UX

[toger5]

This is a tracker/ summarisation issue of multiple issues all addressing the same issue.

• #3723
• #9363
• #11217

possible solutions that were mentioned:

1 add right click option to add parent node

 - clicked node (root)
   - child1
   - chidl2

->

- chooses node to add (root)
   - clicked node
      - child1
      - child2

2 drag and drop to top

- node1 (root)
   - node2
   - node3

-> dragging node 2 above node 1 (line should appear above node 1)

 - node2 (root)
   - node1
   - node3

3 just the option to add a node as the root

could be a simple checkbox in the add node window.
add as root
if not checked it adds the node as the root node.

[Zephilinox]

why not just allow the root node to be reparented like any other node?

[ghost]

I personally like the first option: add as parent. Mainly because it can be used with other nodes too, not just root. I even tried implementing it myself but I couldn't make it work.

Implement the second option alongside could work too.

---

Reparenting also does it for child nodes. For root node, this means all nodes in the scene. That's why you can't reparent root node into itself.

[toger5]

it would be hard to decide which is the next root. but basically it would be just the first child I guess...
that would again lead to some confusion though.

 - oldRootNode
   - child1
   - child2

-> move oldRootNode to child of child1
```cpp

• child1
  
  
  
  • oldRootNode
  
  
  • child2 // would need to become a child of child1 since there only can be one root. that might be unintentional
  
  

[volzhs]

I like add node as parent
it can be used any node in tree.

• root
  
  
  
  • child1
  
  
  • child2
  
  

let's have a another parent node for child1. then we need 3 steps.

1. add a node to root.
2. reparent child1 to new node.
3. move it desired position.

but it can be done with single step if we have a add node as parent

[toger5]

@Noshyaar I agree that adding a new parent node (1) is the better approach. (edit sorry that reference the wrong option...)
But... @Zephilinox is right there also has to be an option to remove root nodes...

wait that might work with the drag drop version...

 - root
   - desiredRoot
      - child1
      - child2

-> drag desired root to the top

- desiredRoot
   - root
   - child1
   - child2

-> remove root

   - desiredRoot
      - child1
      - child2

[ghost]

Removing root is already possible via Save branch as scene option.
(I actually like add as parent (1), not add new root (3) :P)

[Andev08]

Why not have the scene itself as the compulsory "root" parent node, so when you're viewing a scene, that node is "implied" (and not visible in the tree, as everything added to the tree is automatically a child of the "root" which is actually the "scene".

Kill two birds with one stone

[toger5]

Andev08 the issue is, why type of node to choose. a normal node has not 3d transform information wo it would not inherit whatever scaling isa applied to ist child which would Destry a bunch of common concepts in godot

[volzhs]

@Andev08 it sounds like the useless Scene class in cocos-2dx.
what should be done for the hidden root node when adding it to another scene?
I agree with @toger5, it's not fit to Godot concept.

[Andev08]

what should be done for the hidden root node when adding it to another scene?

Well it would show? Clicking the dropdown arrow next to it would show the contents of that scene.

The way it is now (presumably?) is:

-Scene
--Root
---Stuff in that scene
---etc
---etc

And I'm saying it could be:
-Scene/hidden root node
--Stuff in that scene
--etc

[rosshadden]

We already have a reparenting dialog, I proposed in one of the linked issues that we should use it. Somehow. Add a button to it that says "make root node" or something. Any number of things would work and make sense, but just like with dragging/dropping the problem becomes what to do with the old root. I think it should simply get appended to the child nodes of the newly-promoted root.

Swapping a node with the root node, as has also been mentioned, is not a great solution. You lose the child relationships under the node you are making the new root.

[Andev08]

I think it should simply get appended to the child nodes of the newly-promoted root.

This makes the most sense to me as well

[ghost]

@Andev08 I don't understand how hiding root node could retain its properties in case of root node type changing.

One of my common use cases is making a root node a child of something (Generic Node, Node2D, or Control for UI) because I want to extend the scene without losing the properties inside the former root node.

I don't understand how it would work with what you quoted either.

I think it should simply get appended to the child nodes of the newly-promoted root.

Makes sense to me as well. That's what I meant by implementing (2) alongside (1):

 - node1 (root)
     - node2
     - node3

-> dragging node 2 above node 1 (line should appear above node 1)

 - node2 (root)
     - node1
         - node3

It's actually adding (moving) node2 as parent of node1.

[letheed]

Agree with @Noshyaar. If I have

• Node0
  
  
  
  • Node1
  
  
  • Node11
  
  
  • Node12
  
  
  • Node2
  
  

I would expect drag and droping Node1 above Node0 to do this:

• Node1
  
  
  
  • Node11
  
  
  • Node12
  
  
  • Node0
  
  
  • Node2
  
  

[puppetmaster-]

In the ↑ example...
Are you aware, if Node1 has a pos != Vector2(0,0) it would change the position of Node0 and Node2 after reparent.

My use case I meet during prototype phase are always adding a new top node and move everything down. (as already said by Noshyaar)
To simplify the situation during prototyping my root node is most of the times a node2d.

I personally need only the possibility to add a new root node.
The rest can be handled with Save branch as scene.

[letheed]

@puppetmaster- I'd say RMB->"Add a parent node" would fit your needs better than drag-and-drop. There's not reason we can't have both, they cover slightly different use cases.

Typically, when I've wanted DAD, the child node and the root node had the same position. However, in other cases, we can maintain global positions (isn't that already what we do with DAD?):

• new_pos Node1 = pos Node0 + pos Node1
• new_pos Node0 = - pos Node1

[Andev08]

The inheritance properties of parenting is making everything here so much more confusing to me.

In other software (for instance, blender), when you create a new object, it doesn't automatically get parented to something. This means if you realise something is wrong in the hierarchy _after_ you've set up the scene, it's not a huge tangle of passed down offsets to tidy up afterwards.

I believe the core problem here is to do with the inability to have multiple root nodes within a scene. If I'm understanding it correctly, all nodes (including the chosen root node) are children of the scene itself. So having multiple root nodes in a scene wouldn't break anything.

Referring back to a response in a previous thread:

in a standalone scene I can see the benefit, but with inheritance and instancing, there'll be a lot of extra "world" nodes that you won't really need.

This is the case anyway, because every scene has to have a single parent node, which is causing this problem in the first place.

So in this situation:

You drag your new intended root above the current root:

Normally, nothing happens. But this is what I'd expect to happen:

_Also I noticed at this point, no nodes were selected. Unfortunately adding a new node here parents it to the first node in the tree, not create a new parent :(_

From here, you could either put the old root as a child:

Or manually transfer the contents of it

and just delete the old root.

Or alternatively, you could add this to the delete menu:

and then you could delete the root in place after reparenting it to the new root

Following up from this issue, and assuming the above were to be implemented, what if a node deselected itself after being created? When I first start a project, I always import all the nodes I know I'm going to need. Then I look at the tree and go ehhhhhhhhhhhh

I've never had any other software use this behavior

[ghost]

I previously thought one root node per scene made no sense until I realized that root node determines the scene type. Having multiple root nodes per scene hasn't made sense to me anymore since then.

I couldn't imagine what type it would be if I were to instance a scene with multiple roots. For single root it's obvious.

This might be the reason why operations to root node is relatively a big deal.

To have multiple "roots", set the root as one of the generic node types (Node, Node2D, Control, Spatial) and add children to it. The problem is actually here. There's no easy way to add a parent to an existing root node. (Workaround is to make a new scene with a generic node as root, instance the scene and discard instancing.)

After that, "roots" aren't actually root node and it can be as easily managed as other nodes.

By the way, as many others have said, 'Scene' is probably a misnomer and 'NodeTree' is more appropriate.

[djrm]

Scene is the worst name for the best godot feature.

[toger5]

I still like the idea of accepting to have two roots inside the scene dock.
just as a "moving nodes around tool."
That actually would solve this issue really elegant.

It should grey out all the secondary nodes which are on root level but not the first one. and on save it would tell you will NOT be saved so it is obvious that it should only be used as a temporary place...
it just have to be really clear that they are disabled...

[Andev08]

Scene is the worst name for the best godot feature.

Is a Godot scene kind of like after effect's "composition" feature? Everything inside it becomes grouped together, and invisible (but still there). Because if so, maybe the behavior of that could be copied somewhat.

So let's say you wanted to make a composition out of "To_Be_Scene"

So it creates an extra "composition" node that can be renamed to whatever (perhaps naming it comes up as a dialog)

and inside the composition, you have exactly what was in the tree:

Multiple root nodes aren't a problem here either, because they're secretly contained within the base "composition" node. The scene type is held by the composition node, which by default is the node type that the scene was created from (in this case, just a white node). This can later be changed and isn't directly tied to the "root" node(s) of the composition

I still like the idea of accepting to have two roots inside the scene dock.
just as a "moving nodes around tool."

It should grey out all the secondary nodes which are on root level but not the first one

Or perhaps adding extra root nodes could give them the little warning sign you get with unpaired collision shapes:

that if you mouse over, gives a tool tip like: "There can only be one root node per scene, please allocate a parent to this branch".

There's a problem though, because what actually happens to these nodes while they're in the "competing for root" status? I can only assume that if you're viewing an embedded scene, suspended root nodes would get chucked out the scene, and would appear as a sibling to the scene in the parent branch.

So you'd need some kind of flag for "created within scene, but not currently part of it", so that they wouldn't just instantly disappear from the tree. Which is starting to get messy. And what happens if you're in the base scene? They become garbage collector food? There might need to be an "unallocated tree" that's visibly appended to the base scene, but still remains separate.

[djrm]

@Andev08
http://docs.godotengine.org/en/stable/learning/step_by_step/scenes_and_nodes.html
http://docs.godotengine.org/en/stable/learning/step_by_step/instancing.html

[ghost]

I don't understand the use of having multiple roots, since there will still be only one real root. Hiding it really makes it worse in my opinion. It will create inconsistencies between single root scenes and multiple root scenes in terms of node pathing.

Considering this scene, create a GDScript at Spatial node:

If 'Composition' has single root, do I use $Composition/To_Be_Scene or $Composition to refer to the root? Compare to $AnimationPlayer. What about multiple roots?

---

I like @toger5's idea of allowing multiple roots in the dock with only the topmost one enabled. It's almost the opposite of the above implementation as we're not hiding anything and even displaying disabled nodes. I see the use of temporarily 'muting' nodes. There's a question though: are we going to allow switching roots at runtime?

[eon-s]

2 roots? and what should be the root of those roots when saving the scene?
Please no xD

---

Maybe the scene root need a kind of highlight to differentiate it from other nodes so people get better the idea of the importance of roots in tree structures...

[volzhs]

i am against having 2 or more roots.
it will make confusing and another problems.

[ghost]

This is how I imagine @toger5's solution. I agree that it could be confusing if not implemented well.
Note that '(hidden)' is invisible.

Adding a parent to a root can be done by adding new root, automatically disabling old root and its children.

Then adding old root as new root's child, reenabling it.

This doesn't imply multiple roots for a scene. As you can see there is still only one enabled root and it determines the scene's type.

[toger5]

@Noshyaar ty for the example. This is exactly how i was imagining it!
I also started thinking about how to implement that in tscn + scene dock.

Since the disabled roots (we shouldnt call it like that... Maybe "stashed nodes") are compleatly ognored a t runtime and usually just used for node tree reorganization OR testing multiple different node branches we even could color the background slightly red so it is really obvious that they are just temporary and aomething that needs "fixing"

[toger5]

I also would disagree of switching them at runtime... For that you should create tqo proper scenes and load instances of them. And than remove and add child.
It ahould be obvious that it is just for better ux in the scene tree dock. (but i would still save it in tscn so that ppl dont get mad loosing parta of their tree (even disabled parts)

[letheed]

So it does the same thing as other solutions. But with an additional intermediary step that leaves us in an invalid state, where you risk loosing data. And for some reason it allows several roots, something that has no meaning in godot and which some beginners already struggle with.

Please don't do this.

[ghost]

And for some reason it allows several roots,

This doesn't imply multiple roots for a scene. As you can see there is still only one enabled root and it determines the scene's type.

---

Also I think @toger5's intention probably is that it could be implemented alongside (1) or (2), allowing adding as parent in a single step.

[letheed]

Yes but why have this intermediary state at all? It's more work for the user, and leaves you in a new weird state.

That's not something you can do in drag and drop today. Mechanisms should remain consistent at all times. My point is we already have all the mechanisms in place to do this. All we need to do is extend them to work on root. Nothing new to learn for the user. No special casing for roots. So why complicate things?

[letheed]

If disabling part of the tree is something that's wanted, that's perfectly ok by me. But then let's not special case root and allow users to disable any subtree. Drag and dropping a node below the tree would make it an "orphan node".

[ghost]

If we use that solution, we can disable any branch by dragging it to the bottom.

Currently, root is a special case. If you look at the source, several SceneTreeDock functions check whether the selected node is root or not. Also, SceneTreeDock has a Tree control which doesn't allow having multiple roots, unlike ItemList.

I fail to see how it would adversely affect current users as they don't have to worry about these stashed nodes if they want.

[letheed]

@Noshyaar I updated my last comment. So yes we agree on that actully. I'm just wary of special casing root or discrepancies in mechanisms. I also would prefer to avoid unnecessary intermediary steps. It's just more tedious work.

[toger5]

@leftheed there would be NO data loss risk.
It would be more consistent behaviour (behaviour the user is used to) with the stashed node approach.
The one proposed before would be the one with a new behaviour. Since you would drag a node abovr (on the same level than the root. But than the root becomes its child. Which is confusing. It shouldnt when keeping the current bahaviour.
Although im used to the node tree parwnting concept it took me some time to understand the more comolex reparenting examples posted here.

That is also the reson why the intermediate step makes so much sense. It makes sure you understanf what is actually going on and you have the option dmto decide where to add the old root to. (which order)

Anf the additional time it takes to execute the second drag drop is neglectable.

So we get:

• No funky drag to top > two actions occur (moving "one" node above "other" + parenting "one" to "other" behaviour
• consitency. Dragging a node above another node always just moves it (no reparenting...)
• easy to understnad behaviour that is controlled and as a consequence intended by the user.
• the additional feature to just stash a branch of the tree for testing perpuses and add it back later on. Or maybe just to have a helper node with a scrip attached which you want to add and remove real quick (for example a debugging camera with fly control...)

[toger5]

@Noshyaar I would not implement it alongside 2. Since that would mean dragging to the top results in moving and parenting so it wpuld conflict with the just moving approach. But 1. Definitly can be implemented alongside.

[Zireael07]

I don't see the appeal of "two roots" approach and/or disabling parts of the scene tree.

I think 1 or 3 from OP would be the best solution. Originally I was in favor of drag and drop, but breaking consistency is a very big con.

[toger5]

@Zireael07 it is not the appeal which makes me convinced it us a good solution.
It is just annoying (almost feela broken) that you can drag a node everywhere except the top.

Thinking of the issue of changing root from a beginners perspective i would guess, that she/he would try dragging... That does jot work which is frustrating. Finding out that you have to right click could be hard. Dependent on the users previous software experience...

And im kind of against two since as you said breaking consistency is a big con.

That we have node in the process that are disabled is kijd of given than and since it has some other advantage it also does not hurt.

Im trying to say that i dont propose it for the feature of having stahed nodes (secondary roots or however you wan to call them) I want the best root changing experience and that seems to be the most consistent and easiest to understand without leatning about it from someone else or the internet.

[letheed]

@toger5 But your approach is not more consistent since currently DAD above keeps everything else in-tree, whereas now it might disable parts of the tree if and only if you DAD above the root node.

What you want is really another mechanism:

Orphan nodes: nodes that are part of the scene but not the scene tree (hence not rendered)

• DAD a node below tree orphans it.
• "Orphan node" or "Orphan subtree" action in contextual menu.

[letheed]

Admittedly, if we want to remain consistent, we might need both, eg:

• DAD right above root makes node the new root and childs old_root to it. We could make that one obvious by moving the current root and subtree rightwards to where they would vertically be after reparenting root.
• Bring up the mouse a few pixels and the tree returns to its original vertical position. The horizontal bar moves up a bit. If you drop now, it orphans the current root instead of reparenting it.

I think I've seen some software do that.

[volzhs]

what are we trying to solve?
with 1,
it can be solved root node problem.
it is simple. no guess. no study. no confuse.
it also can be useful for every node, not just for root.

[letheed]

@volzhs 1. is good when you want to add a new node as parent, not for reusing an existing subtree.

[ghost]

(1) would solve changing root by adding a brand new one as parent. Stashed node would solve not being able to drag root node around.

[letheed]

I think it's still only a workaround. There are regularly bug reports/comments/question threads on forums from beginners asking why they can DAD a node above root to make that the new root. Simply because it's the most intuitive thing to do and the first thing they try out. We'll keep getting some of those until it is implemented. There doesn't seem to be a single strong argument against it, so I'm a little bit puzzle at why there is so much resistance to something this simple and straighforward.

[reduz]

I think all problems described could be fixed by using the RMB menu (which
is getting quite crowded btw), and options like this, that only appear when
you RMB the root node:

1) "New Parent Root" - Add new root and make existing root a child of it
2) "Remove Root" - Removes the root node, only works if root has one
children, otherwise shows a warning that option only works with 1 children
of root

On Fri, Sep 15, 2017 at 8:24 AM, Poommetee Ketson [e-mail]
wrote:

(1) would solve changing root by adding a brand new one as parent. Stashed
node would solve not being able to drag root node around.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/11238#issuecomment-329755309,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z29pNEPQKyEQCgLzEdZLqkFj43m9Bks5sil6LgaJpZM4PWOYp
.

[letheed]

@reduz What about the case where you want to use a child node (and its children) as the new root.

[reduz]

@letheed The fact you cant create a new root using drag and drop is, in fact, what makes it intuitive to me. Going with solutions having several roots just makes it confusing.

[reduz]

@letheed It's as I describe, go to the root node and select "Remove root", it will make the child node the new root. Maybe it could have a better name, like "Make Child Root"

[reduz]

or "Replace by Child"

[letheed]

If i understand correctly, that deletes root, which may not be what the user want.
It also means you need to drag every other child node of root under the one to be the new root beforehand, or you won't be able to "Remove Root". Which may not be obvious to the user.
Then readd a node of the same type as the old root under the new one. Reparametrize it, which may not be all that trivial. Then re-drag all the nodes that you want as its children under it.

[reduz]

@letheed it will be obvious to the user because a proper warning will be shown if he or she attempts to do this with many children.

Still, I have been thinking, and definitely the best way to fix this in my mind could be an option to click on any non-node and have an option "Make as new root"

This will make that node and all children of the new scene, while old root and other nodes (including other parents of this node) will immediately become children of it. I think this is even better because it covers all use cases I can think of..

[letheed]

Hmm, aside from making it a context menu action, how does that differ from the DAD proposal?

[reduz]

@letheed I'm not sure if it's the same thing, but this is something you definitely not want as drag and drop, as It's impossible to convey what the action is this way. RMB option makes a lot more sense in this case.

[letheed]

DAD is the first thing new users reach for when trying to replace the root. It is intuitive. It has been repeatedly asked for. I must confess I am left a bit puzzled and at a loss by the opposition to it. I have yet to see a single good argument against it. Maybe I'm missing something and someone can explain to me what is so terrible with it.

[Zireael07]

@letheed: DAD moves the node. That it all. But for replacing the root, it needs not only move this one, but also affect other nodes (reparent them)

[letheed]

@Zireael07 So?

[Zireael07]

So we want consistency (DAD should only move the node in ALL cases)

[letheed]

Yeah, but the point of consistency is to make things intuitive and unsurprising. And we're talking about something that people are already reaching for. So intuitiveness is not a problem in this case.

Secondly, changing the root implies reparenting the current root node or deleting the current root node. The second of which I'd prefer to avoid.

[Andev08]

I don't think there's any intuitive situation where dragging a node above another node makes the dragged node the new parent. You just have to look how nodes behave already when they aren't root:

It either becomes a child or a sibling, not a parent itself.

the scene root needs a kind of highlight to differentiate it from other nodes so people get better the idea of the importance of roots in tree structures...

How about a simple tweak like this:

Where the first node in the section of tree being viewed (which will always be the root node), gets its own privacy booth.

And if you drag a new node over the root node:

Or

[reduz]

As mentioned before, a RMB item is the way to go, there is no need to make
the drag and drop code, which is already complex, worse for a not as common
use case which can be perfectly be solved with an item.

On Sep 15, 2017 11:30 AM, "Andev08" [e-mail] wrote:

I don't think there's any intuitive situation where dragging a node above
another node makes the dragged node the new parent. You just have to look
how nodes behave already when they aren't root:
[image: reparent]
https://user-images.githubusercontent.com/31744099/30486160-8e4b760a-9a27-11e7-96ca-fb511898e1c0.gif
It either becomes a child or a sibling, not a parent itself.

the scene root needs a kind of highlight to differentiate it from other
nodes so people get better the idea of the importance of roots in tree
structures...

How about a simple tweak like this:
[image: image]
https://user-images.githubusercontent.com/31744099/30486698-3c2bc472-9a29-11e7-88c4-0b340f20dadb.png

And if you drag a new node over the root node:
[image: swap]
https://user-images.githubusercontent.com/31744099/30487207-b136b9ec-9a2a-11e7-86b7-4fe35055d6ee.gif

Would this not solve all the problems here?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/11238#issuecomment-329799288,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2337mV_8YyxqySWrDvQTH2lD0MKNks5siooQgaJpZM4PWOYp
.

[Andev08]

But as people have mentioned before as well, drag and drop is the most intuitive implementation. It also requires less clicks and time, and doesn't break your workflow to stop and think "now how do I get that node where I want it?"

[hubbyist]

RMB "Promote As Root Node" option is the least confusing and fastest to implement it seems. Old Root will become the ''last child'' of New Root with all its children in this case and scene can be further worked on after that I think.

This will also work as add "New Candidate Root" then RMB "Promote As Root Node" work follow to change scene root.

[Andev08]

Could I suggest a nitpick of "Set as Root Node" rather than Promote? I feel like the word "promote" overcomplicates what it's doing.

[letheed]

@Andev08 Well given that a root node can't have sibling, I don't think that's much of a problem. I do understand concerns about users understanding an action's consequences though. For that a visual cue of reparenting would be a big plus indeed. I've already proposed moving the tree to the right, to a "child position", which I think could work well.

@reduz I understand your argument about code complexity. All I can say is that someone must pay some price, and if it's not the dev then it's the user.

• The contextual menu is already quite crowded. And we're just adding on to that. Reaching for it is an easy solution from a dev perspective, but this will need to be solved one day.
• I think the UX will be subpar to what we could provide. Reorganizing the existing nodes should not require the use of buttons or menus.

[rosshadden]

@letheed In complete isolation, the context menu is the best solution for this. Yes it's crowded as many have pointed out, however that doesn't mean we should implement a subpar fix to avoid that issue. We should figure out a way to make it less crowded, with grouping/nesting or something.

I agree that someone has to pay some price, but there's a third agent there: the context menu. He's willing to pay the price, and it doesn't really negatively affect the user _or_ the dev. Yeah it adds to the crowding, but at this point it's n+1 where n is already high.

[Andev08]

In complete isolation, the context menu is the best solution for this. Yes it's crowded as many have pointed out, however that doesn't mean we should implement a subpar fix to avoid that issue.

Drag and drop is not a subpar fix, it's the first thing I tried to do, and I'm not alone in this.

I think we can all agree workflow is important, and D&D is the fastest and most efficient way of reordering objects (it's one click, in contrast to selecting an item from a dropdown, and navigating various popups, menus and selections).

I also don't think it should be the only method, but having both doesn't seem to be on the table.

but at this point it's n+1 where n is already high.

You could also say: "Drag and drop code is already complicated, at this point it's n+1"

But I honestly don't think "it's already broken" is justification to break something more. At some point, someone is going to have to fix it. And the more it gets broken, the more intimidating the task is.

[Andev08]

He's willing to pay the price, and it doesn't really negatively affect the user or the dev.

We are no longer discussing what's best for Godot, we're discussing how little work has to be done to get the minimal working solution. And that's not good for the future of the software :/

[rosshadden]

From my perspective anything that requires touching the mouse has already lost the efficiency battle. I realize Godot doesn't currently have good universal keyboard-centric workflows anyway, and thus it's not really worth picking this battle to start that. But I do at least want to mention it.

I'm sure anything we implement will be easy to adjust to and make us all happy. In the end we're all just trying to make Godot better.

[toger5]

Also im willing to do the d&d change.
Haven't got any time over the weekend though...
(just for the perpus of discussing: I think code does not behave like n and if n is high n + 1 has little impct. The opposite is the case. With every feature you add to complex code you make it much much more complex. Take more time to implement it and more time to understand it in the first place as someone who wants to work with it.)
But * also Think we should do the best possible even if it is harder. (but time to Klops.ent also should be a big point since Projects like a game engine are of somehow unlimited scope. So every feature which takes more time steals time from something else.
@rosshadden true, I also think a really Good shortcut Setup is worth A LOT.

[Andev08]

Also im willing to do the d&d change.

That's great!

every feature which takes more time steals time from something else.

Quantity vs quality. Would we rather a pile of unfinished / broken functionality, or less functionality but it all works seamlessly?

[toger5]

@Andev08 agreed!
Feature in terms of something that improves godot. Not in terms of sth new.

[Oranjoose]

I completely agree with @Andev08 that drag and drop is by far the most intuitive system for reordering node hierarchy, root node included. Any program with a layers panel, scene hierarchy, events list, or similar menu can expect that the very first thing the user will try is to drag and drop the elements to reorder them.

The way Unreal does it is pretty intuitive. If the dragged file is a direct child of root, then it automatically makes the dragged file the new root. If the dragged file is a descendent past direct child, then it supplies a context menu asking if the intention is to make the dragged file the new root, or to attach it as a direct child of root:

[reduz]

What we discussed last time about a RMB option is probably the best, I will
note it so its done before beta

On Fri, Oct 27, 2017 at 6:17 PM, Oranjoose [e-mail] wrote:

I completely agree with @Andev08 https://github.com/andev08 that drag
and drop is by far the most intuitive system for reordering node hierarchy,
root node included. Any program with a layers panel, scene hierarchy,
events list, or similar menu can expect that the very first thing the user
will try is to drag and drop the elements to reorder them.

The way Unreal does it is pretty intuitive. If the dragged file is a
direct child of root, then it automatically makes the dragged file the new
root. If the dragged file is a descendent past direct child, then it
supplies a context menu asking if the intention is to make the dragged file
the new root, or to attach it as a direct child of root:
[image: unrealassigningnewroot]
https://user-images.githubusercontent.com/15862731/32125603-b7791fbc-bb3a-11e7-9d3b-65a2383abf66.gif

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/11238#issuecomment-340088276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2yEa9c4vWRREhOLpP-Hwe8nEeVEVks5swkiAgaJpZM4PWOYp
.

[mhilbrunner]

Whats the status on this?

[Eoin-ONeill-Yokai]

Are people still interested in this feature? Do we also have the greenlight from the developers to add it?

[mhilbrunner]

@TheYokai Sure, adding a RMB option as suggested above by reduz should be fine and would def. be welcome I think

[Kinrany]

The docs describe scenes as nothing but trees made of nodes. Is this really true? Is this how Godot really treats them?

Because if it is, there should be no reason ever to treat the root node as special.

It's counterintuitive that there can't be more than one root in the tree editor. If the root is really special, then it shouldn't be in the tree at all. That's how other game engines, file system explorers, and outliner software with tree structure do it, to name a few.

I'm just starting to use Godot, and to me it looks like roots are treated as special because the editor wants every node to be a part of a scene, like text editors that don't know how to edit text without creating an empty file for it first.

I see two good solutions here:

1. Hide root nodes, use only empty nodes as root.

   a. For backwards compatibility, have a "hide root node" switch.

2. Replace the scene tree editor with a node forest editor. Make it possible to have nodes not associated with any scene, and scenes associated with non-root nodes.

[Eoin-ONeill-Yokai]

I just made a patch and examined the code so I'll try to answer based off of what I know. I'm no expert, but here's how I see it, @Kinrany .

The docs describe scenes as nothing but trees made of nodes. Is this really true? Is this how Godot really treats them?

Because if it is, there should be no reason ever to treat the root node as special.

Nodes and scenes truly are one in the same, but the way you "edit" a scene currently is that the editor points directly to a node as the "root". So, in essence, the editor is saying "Hey, I'm editing this node here" and that becomes the root node -- so if you had multiple "root" nodes, you'd actually have multiple scenes loaded in the same view port. One could argue that multiple scenes loaded as multiple "roots" would be a neat feature, but it would also require some changes to the way the editor handles the "currently edited scene" which would be a major refactor. It may still be worth visiting at some point.

It's counterintuitive that there can't be more than one root in the tree editor.

There are some benefits to the design, despite it being counter intuitive. The major one is that it quickly tells the user that a "node" and a "scene" are one in the same thing. Your scene can be a Node, AudioSamplePlayback, AnimationPlayer, Spatial, and so on and so on. So really, your scene has a "type" that is defined by the lowest level node. You can guarantee what type your scene is and therefore you can intuitively call functions into a scene when it is instanced. One could argue that a scene could have a hidden "Node" that acts as the root, but this would also mean that your scene would lose it's ability to be typed and would require the user to navigate to their desired subnode by node name (which would be less than ideal.)

In reality, wouldn't the issue simply be resolved by creating a UI that makes the root node "concept" more intuitive? For example...

This tells the use

• Your scene is a Node, with the type of Node2D and the name "Node2D"
• The root position is spaced differently than the other nodes and has a thicker dividing line, indicating that all nodes below it belong to the "scene" itself.
• The scene icon is an indication of what a root node is -- it IS your scene (as you've defined it.)
• In the future, you could theoretically allow users to drag nodes into the same layer as your root node, but you would be prompted to make a new scene. Saying yes would them prompt you to save a file. After saving a file, you would have another scene connected to the root. When you CTRL+S, it actually saves all scenes loaded by the editor to their respective assigned filenames. When you run, it essentially treats the other non-top scene as "load on start" scenes.

I agree that the UX UI could be improved, but I think that the typed scene system is actually a benefit to the user beyond the User Interface implications. I think the data should stay the way it is, but the way the user interacts with the data should change.

[Kinrany]

The major one is that it quickly tells the user that a "node" and a "scene" are one in the same thing.

That's the thing, it doesn't right now. So yeah, I agree that visually separating the root node from the rest would be an improvement. It should have different affordances too. For example, hiding or collapsing it doesn't make sense, does it?

I haven't considered the benefits of the root node being typed, sorry. Is it true that there are basically two use cases: scene as a list of nodes logically separated from the rest of the tree, and scene as a reusable element that looks like a single node from outside?

(I still think editing multiple scenes in the same window is a must-have, but that should probably be a separate issue.)

[Eoin-ONeill-Yokai]

It should have different affordances too. For example, hiding or collapsing it doesn't make sense, does it?

Perhaps for collapsing, but hiding should be exposed because the state of the root object is the state the object has when it is instances as a scene. For instance, if you want to instance a scene node as being invisible on spawn, you simply set the visibilty of of the root layer to be invisible. The settings the root node has will be carried over into any other scene it is initialized within (which makes it a convenient utility.) It's worth noting that, if your root object (scene) doesn't need visibility, you can simply give it a type that doesn't have a visibility marker (like a regular Node type).

Is it true that there are basically two use cases: scene as a list of nodes logically separated from the rest of the tree, and scene as a reusable element that looks like a single node from outside?

Yes, somewhat correct. However, when you instance a scene, you can navigate to sub nodes and treat it like any other part of your hierarchy. However, depending on taste, you may want to simply call methods on whatever the "root" object of your scene is. The flexibility is basically on a per user basis.

(I still think editing multiple scenes in the same window is a must-have, but that should probably be a separate issue.)

Yes, but I think it's worth bringing up in the case of talking about the significance of the "root" node itself, because a root node concept will actually make more sense to users when they see multiple "scenes" loaded as separate roots in the tree.

[mhilbrunner]

As stated in https://github.com/godotengine/godot/pull/19035 there is now an option to make a child node the new root node.