Present the root container as the top-level viewport container and differentiate it from other container

[abey79]

The Blueprint Tree is currently presented with the root container at the top of the hierarchy:

This causes two issues:

• The root container being, by definition, always alone at its level, it causes significant right-ward indentation for not much user benefit.
• Since nothing can be inserted after or before the root container (again, by definition), it behaves somewhat unexpected with the drag and drop introduced in Add support for drag-and-drop in blueprint tree #4910.

In order to acknowledge the fundamental difference between the root container and all other container, and adjust the presentation to highlight that different and address the current shortcoming, we propose the following changes:

1. The root container no longer has the the collapsing triangle and thus cannot be collapsed. This allows left-shifting the entire tree.
2. The root container is named differently than other containers, for example "Viewport (Grid)"/"Viewport (Horizontal)"/etc.
3. The root container is no longer draggable (though it is now draggable, it's impossible to find a suitable target drop anyways).

Appart from these changes, the root container would remain selectable/editable as it currently is (maybe with minor adjustment in the selection panel to acknowledge its difference).

Mock-up:

[nikolausWest]

Let's go with this approach. The alternative, which would be more similar to html or SwiftUI is to have an implicit vertical container at the root. However, I still think it's nice to have an explicit root to put global overrides on for instance so lets go with this

[abey79]

Yes. If you want something else than a vertical container as viewport root, then you can set it and dont have to "manually" create a "sub-root" to achieve that effect.

[nikolausWest]

Hmm... we actually need to think through how this interacts with the SDK.

• Do we have a special Viewport container that you can use?
• What happens if I set up a hierarchy without a Viewport, do we wrap it in a viewport or convert the outermost container to a viewport?
  • If we convert it, that means I can never put that container in another container after the fact. If I've set overrides and options on that container that's kind of annoying.
  • On the other hand if we just document that the root container will represent the viewport and can't later be moved that might just be fine

[abey79]

Do we have a special Viewport container that you can use?

I don't think so. I'm not clear on the API details, but I'm anticipating that wherever we setup the viewport content, we can specify either one container (which will become the root), or one space view (which would then be the only viewport content, and will be added to an implicitly create root container).

that means I can never put that container in another container after the fact

By definition of a root container (whether or not we give it a special treatment), we cannot move it anywhere, because a container may not be moved inside of itself.

You may move item around (before/after) the root container, but performing that operation means implicitly creating a new root container and adding both the newly moved item and the former root container in it. That's what we want to avoid here.

On the other hand if we just document that the root container will represent the viewport and can't later be moved that might just be fine

That's exactly the spirit of this issue.