Sounds like an interesting approach for handling UMG interaction.
But I would “need” the widget inheritance for the actual widget design.
Like here:
I have PercentileBasicUI widget. Just a background image, a progress bar, a text component and another image as icon.
With a “SetData” function, the user can set the value for the percentile:
(The “Value” and “Total” variables that are set are private)
So, after the value is set, the UI is updated:
The various update functions for each component:
Nothing is done to the icon in the base class. Descendant classes could then overwrite this function to add icon update logic.
Although probably never needed, descendant classes could overwrite this function to modify the displayed bar value.
This is the method that a descendant class would overwrite to have the value displayed differently. For example: Ammodisplay “15/20” Healthdisplay “75”.
So, with your approach, I might be able to move that logic into another class and have my widgets controlled from there like shown in your diagram.
But what if I want to extend the widget to have another text component above the bar to make a “CaptionedPercentileUI” widget?
Sure, I could create a new widget, and drag the Percentile in as a component, but then that gets messy when you rearrange things in the hierachy…
How do you keep changes in your UMG setup in sync with yyour “Manager” class logic ?