Runtime Bindings outside of UI-Toolkit?

Unity Engine
, , ,
1

I’ve been reading about Unity’s new Runtime Data Binding and looks very interesting. However it seems that it has been specifically designed to work for UI Toolkit.

Is it possible to use it, for example, to create bindings to values outside of a UI element? To react, for example, when a value changes. I’ve checked the documentation and delved in the UI Toolkit code but I couldn’t understand if it’s not meant to be used outside the UI Toolkit scope.

2

I don’t think it is, or can be used outside UI Toolkit. All the methods to managing bindings, SetBinding, etc, are part of VisualElement or the UI Toolkit framework. Potentially there’s something going on that can be reused, or recreated outside of UI Toolkit, but you’d have to look into that.

3

Yeah… I’m afraid you’re right. I tracked it all down to this DataBindingManager, which contains the bindings collection. Unfortunately it’s also under the UIElements namespace and it’s marked implicitly as internal.

Would be incredibly useful if this were to be decoupled from UIToolkit, but there might be technical reasons why it can’t be (maybe VisualElement’s scheduler?)

4

Yes the bindings are ran/updated through the UIToolkit updaters logic. You could try having a dummy panel and invisible visual element to experiment running them but that has not been our primary use case and the most tested codepath!

5

Okay, thanks for taking the time to answer!

6

The binding system was made specifically for UI Toolkit, but conceptually, it could be generalized to be usable outside of UI Toolkit as well with some changes.

A few reasons why we limited it to UI Toolkit:

  • We have clear APIs for lifetime management (for example, bindings are automatically un/registered when removed/added to a panel. A generalized solution would require users to be more specific in their usage.
  • We needed a way for the data source to be inherited in a hierarchical fashion.
  • We needed to update the bindings at a specific time during our own update.
  • We needed a built-in way to be notified of changes from the controls to avoid pulling that information during the update.

Constraining it to UI Toolkit allowed us to make it easier and safe to use.

7

Makes sense. Thank you too for answering. I’ll dig deeper into the UIToolkit code reference and see if I can work around it.