Graph layout support

[reeseschultz]

When thinking about graph layouts, Path of Exile’s skill tree comes to mind, and even Wall of Text’s touted “infinite canvas.” Graph layouts are a common use case. Thankfully with absolute positioning graph layouts can be achieved with UI Toolkit since Yoga observes this W3C standard whereby absolutely-positioned children are taken “out-of-flow.”

Now, in this comment by @uDamian , he remarks, “Absolute positioning is actually actively discouraged and only useful in special cases (like drag and drop ).”

Doesn’t it follow that any graph layout with absolutely/arbitrarily-positioned nodes is considered a “special case” in the context of UI Toolkit? I would agree that it is a special case, despite being common, since, in the web world, drawing edges between nodes has entire libraries such as Cytoscape dedicated to that purpose. Since graph nodes feature so much interactivity, CSS and markup just aren’t enough. That’s not to mention handling input/output between nodes, dragging and dropping, multi-selection, etc.

So this brings me to another tangentially-related comment : “GraphView was never released for public use and is not supported. It is unlikely to receive any updates.”

With that, the overall impression I’m getting is that users should not expect high-level graph layout support in UI Toolkit, although it will probably continue to pass-through conventions from Yoga, meaning we (the users) should be fine to build higher-level graph solutions on top of UI Toolkit via absolute positioning. Is that correct? It is it anticipated and recommended by the UI Toolkit maintainers that the users do this going forward?

I’m also assuming GraphView won’t be replaced or released for public use. Is that the case? Finally, please keep in mind I’m not criticizing—I’m evaluating. I totally respect avoiding scope creep if that’s what’s going on, since I’m assuming Unity has bigger fish to fry. I’m just looking at UI Toolkit for incorporation in a game making extensive use of graph layouts, in which children of graph nodes would still benefit from flexbox. Further, all my other UI would also benefit from flexbox as well. I’ve built frontends with flexbox for years and love it. But if I learn that I should not build graph layouts specifically with UI Toolkit, I could move on to evaluate alternatives such as UIForia instead.

Thanks in advance for your time.

[uDamian]

@reeseschultz

With that, the overall impression I’m getting is that users should not expect high-level graph layout support in UI Toolkit, although it will probably continue to pass-through conventions from Yoga, meaning we (the users) should be fine to build higher-level graph solutions on top of UI Toolkit via absolute positioning. Is that correct? It is it anticipated and recommended by the UI Toolkit maintainers that the users do this going forward?

This is entirely a situation where we had to focus and prioritize and GraphView just didn’t come up on top. There are no technical reasons why we don’t yet offer a public API for graphs in UI Toolkit. Just hasn’t been done yet. We needed something for our other teams working on ShaderGraph and VisualEffects Graph (and others), so that’s why GraphView exists. But after evaluating the required effort, we decided to hold off on investing to make it public (and therefore forever maintained). There are internal efforts to eventually have a reusable graph UI system but nothing specific to share at this time.

What I said about Absolute position does indeed include graph UIs as part of my “special cases”. I used that language to make it clear that Absolute should not be used for things like anchoring elements to the bottom of the screen, or offsetting elements from each other. We are trying to make the workflow for Relative positioning more intuitive via the UI Builder but for now, there’s always this urge to just use Absolute to do what Relative is designed to do. But Absolute is absolutely supported and will always be supported, specifically because it has many legitimate use cases, like graphs.

@reeseschultz

I’m also assuming GraphView won’t be replaced or released for public use. Is that the case?

GraphView, in its current form, is indeed unlikely to be made public. Like I said above, there’s some internal efforts to create something “like” GraphView for public use but don’t expect anything this year at least. That said, I’d still recommend using GraphView instead of starting from scratch. We will definitely not remove the APIs for GraphView for a very long time and not until a replacement is generally available. Remember that released products like ShaderGraph rely on GraphView today. There’s also this unofficial effort to cleanup up GraphView a bit that may be worth a look:
https://github.com/alelievr/NodeGraphProcessor

@reeseschultz

I’m just looking at UI Toolkit for incorporation in a game making extensive use of graph layouts, in which children of graph nodes would still benefit from flexbox. Further, all my other UI would also benefit from flexbox as well. I’ve built frontends with flexbox for years and love it. But if I learn that I should not build graph layouts specifically with UI Toolkit, I could move on to evaluate alternatives such as UIForia instead.

If you’re comfortable with flexbox and the mixing of Absolute and Relative, by all means, use UI Toolkit to create your graph UIs. We may not be able to fix bugs or support you when it comes to the GraphView API itself (if you use it), but for any issues related to Absolute-positioned elements with Relative positioned child elements are totally fair game. We still use GraphView for all our UI graphics performance and stability testing to make sure the use case is fully supported.

[reeseschultz]

@uDamian I really appreciate the time you put into answering my questions. No worries about GraphView support, NodeGraphProcessor looks well-maintained and very relevant to my interests. Plus, I’m just happy to have assurance about support for absolute positioning. Thanks!