Passing an entire IView over the Pintail API boundary is a non-starter; there are far too many methods and types involved, plus it's just going to overwhelm the StarML users with complexity.
However, to solve for the case of HUDs and other non-menu UIs, we can define a much simpler interface that is based on IView and can be implemented by DocumentView or a wrapper around it:
These three simple methods should cover about 95% of use cases, since all other view properties can be set in the markup itself.
I'll note explicitly that there's no Update(TimeSpan) method here because, since it is being produced by the Framework mod and is not part of the Core/shproj, we can have the API hook it into the game's update loop automatically and drive the update this way.
Possible tweak: Have Vector2 Position { get; } and Vector2 AvailableSize { get; } properties instead of Measure method, as we can also drive the Measure from the aforementioned update loop. However, Draw still needs to be explicit, because the framework mod has no way to know when - as in, which rendering event/step, in what order, etc.
Having a 1-line draw call in some caller's ModEntry is still a pretty good outcome, IMO.
Passing an entire
IView
over the Pintail API boundary is a non-starter; there are far too many methods and types involved, plus it's just going to overwhelm the StarML users with complexity.However, to solve for the case of HUDs and other non-menu UIs, we can define a much simpler interface that is based on
IView
and can be implemented byDocumentView
or a wrapper around it:These three simple methods should cover about 95% of use cases, since all other view properties can be set in the markup itself.
I'll note explicitly that there's no
Update(TimeSpan)
method here because, since it is being produced by the Framework mod and is not part of the Core/shproj, we can have the API hook it into the game's update loop automatically and drive the update this way.Possible tweak: Have
Vector2 Position { get; }
andVector2 AvailableSize { get; }
properties instead ofMeasure
method, as we can also drive theMeasure
from the aforementioned update loop. However,Draw
still needs to be explicit, because the framework mod has no way to know when - as in, which rendering event/step, in what order, etc.Having a 1-line draw call in some caller's
ModEntry
is still a pretty good outcome, IMO.