To elaborate on what @jesusdesantos said:
Our middleware is designed to be integrated into game engines. As such, it declares some interfaces for the engine integrators to implement, to handle things like rendering and input. The UE4 plugin is built on top of this interface, and provides an implementation for those that uses Unreal’s abstractions for handling rendering and input. It also offers some Unreal specific functionality, like the ability to bind data and commands to Blueprint variables and functions.
The main runtime class is called NoesisInstance, which are generated by our Blueprint derived class NoesisView. It derives from UserWidget, which means it can be used anywhere an UserWidget can. It is created using the same CreateWidget function, added to the viewport the same way, it can even be used with the WidgetComponent. It’s also the way we handle input, which means that you also use the same functions for that as with UMG (SetInputModeUIOnly, etc.). The only caveat is that if you create a regular UMG Blueprint, our NoesisViews don’t show up in the same place as the UMG Blueprints because the editor explicitly looks for Blueprints derived from WidgetBlueprint, and ours isn’t. I’m sure we could work around this if it’s a deal breaker, either by changing the base class of our NoesisView, or by creating another Widget derived class that offers the same functionality.
As for rendering, we don’t create UMG widgets. In fact, as I said, from UMG’s point of view, a whole NoesisInstance is a single UMG Widget. We render through the Widget Paint interface, though. We have a CustomDrawer that is executed on the render thread, and we interact directly with Unreal’s RHI.
You mean having to rewrite them from C#? I’m afraid that’s impossible to get around. Having to keep the XAMLs inside the Content folder is something we could potentially get around. It should be possible to do it now if no absolute URIs are used, but we could also add the option to set the root path on the project plugin settings. I decided against this option because I’ve used it in the past and it’s got its own issues (people forgetting to set it, and inevitably at some point someone wants different roots for different files, at which point the whole thing becomes a mess). I went with this route because it felt natural given the way Unreal automatically imports assets in that folder and places the UASSET in the same folder. But I’m open to changing it if it’s too disruptive for people’s workflows.