Easier-Binding of NovaUI Elements to Data Model/Controller

[najak3d]

As I'm extending the concept of Dropdown to enable a Deep Multi-Select menu, the most difficult part about this was the confusion from a lack-of-binding/association between the UI components (ToggleVisuals, ItemView) and the Data Model (the actual data that each ToggleView entry represented).

I ended up modifying some of Nova's code to kludge this for now such that at the time of Expansion, when BindOption() calls are being made, I'm tightly associating my UI elements to the corresponding Data Selection Tree model.

This then allows me to simply "change Selected Item" or even "Selection Depth level" on the model, and then call "UpdateVisuals()" when then my DataModel/Controller traverses itself and ensures correct UI Expansion, Selection, and Hover states.

This is semi-traditional UI model of "Update the Model, then Update the UI to match" (MVU?) -- and when the UI interacts with the model, it's the same thing -- it ONLY modifies the Model, then Updates itself to match the new state of the model. For cases where efficiency is an issue (the model is too large, and full-traversal is too expensive) - you can always implement a "UIDirty" concept for changeEvents at any level, such that you can just have parts of the UI respond to change. But my default is to not-optimize.... come up with One Routine which fully updates the UI Presentation to match the DataModel -- then whenever the DataModel changes simply call this One Route, "UpdateVisuals()".... this routine is non-wasteful, in that it simply Disables (without disposing) of UI clusters that get collapsed... so there isn't memory thrashing. It's as simple as visiting each expanded/visible element of the UI and ensuring it matches the DataModel (which normally it does, and so requires no action).

This is the premise upon which Flutter UI works, which is exploding on adoption.

===
ONCE I got it configured LIKE THIS (DataModel/Controller associated to all View Model elements), everything started working and making good sense.

The default method of operation for the sample NovaUI controls does not work like this... it's largely disconnected from the data model.

I'd like a mode of NovaUI, where the UI "direct responses" (like Hover, Pressed, etc) - can all be disabled, and have all of these set by the Data Model/Controller itself.

Keyboard Hotkey+Wheel Integration:
In our UI, we make heavy use of Keyboard hotkeys -- such as "Alt" key will open the current Brush selection Multi-Select menu, and then allows you to use Wheel mouse to modify the selected item... and moving Mouse Left/Right to change the Level of Selection... it defaults to "Leaf Node" but Alt+MouseMoveLeft, will take you up the hierarchy one level, so now Mouse Wheel selects the index on "one Menu level up", and so on. This allows you to interact with the UI with much less workload.

For example, when World Editing, you may not want to lose your world position where you are painting -- so you tap "Alt + Wheel" to change your brush quickly, and then resume painting with the mouse right where had it.

NOTE: We're debating on how to change Selection Level -- MouseMoveLeft/Right does change mouse position, so we are toying with "Alt + Ctrl" will make Wheel change the Selection Depth, and thus allow full brush selection to occur, from a NovaUI menu-like UI, without ever moving the mouse.

Of course, moving the mouse and manually doing this must also work. And so we're implementing this where our DataModel is also the Controller -- change the Model, and tell it to "UpdateVisuals()" and it does. Likewise, we're disabling the NovaUI direct responses to Hover/Pressed/etc -- and feeding those events to the DataModel, where "UpdateVisuals()" again induces the update.

This then gives us the easy option to DISABLE mouse hover/press, whenever the Alt key is pressed, to avoid confusion. Alt-key mode will ONLY use the wheel + Ctrl to modify the menu selection. Release Alt, and the menu cluster disappears.

===
Again, the biggest headache we had was in Initializing the associations between NovaUI instances of "ToggleVisuals, ItemView" and the DataModel tree of actual Brush Options, thus enabling the DataModel to fully control the state of the NovaUI Visual elements (i.e. Expansion/Collapse, VisualState/Mode, and Selection).

Here's a screenshot of our menu cluster, currently only 2 deep, but for terrain will soon be 3 deep.