Removing AbstractUI requirement from Cores and the SDK

[Arlodotexe]

Background

When designing the core interfaces, one of the questions that we had to ask ourselves is "How will cores provide a generic settings UI to the user in a way that doesn't tie us to a UI framework?"

Ultimately, this led to the creation of AbstractUI, a set of models that represented simple UI elements, and could be abstracted as pure data (to account for out of process cores).

Where we are now

AbstractUI is used in all current cores as creating an AbstractConfigPanel is a requirement to implement ICore.

Headless cores have always been at the back of my mind during the development of the SDK. Though we've never actually instantiated a core headlessly, it's something I've been creeping towards while evolving the architecture.

While writing documentation for creating a core the other day, in order to make headless cores a standard thing, I made it a suggestion for all cores to expose a configuration object (usually the actual core settings) in the constructor. Again, we hadn't needed this, but I knew we were going to, especially if we published in a nuget package.

Then it dawned on me: The AbstractUI panel only serves to set these settings internally in a core. Why not just set them directly, before the core is ever instantiated?

Proposed changes

With the above in mind, my proposal is to remove ICore.AbstractConfigPanel and all dependency on AbstractUI from the SDK.

There's a few clear benefits to this:

• All cores work headless by default
• We can remove the weirdness around listening for the CoreState.NeedsConfiguration state to know if you should show the config panel.
• Creating a core is much simpler. You don't need to create a settings UI - you directly expose the settings and maybe some setup helpers.
• Configuring a core can still be done with AbstractUI, it just wouldn't be embedded into the core. This still allows us to do remote cores.
• Not being bound to AbstractUI limitations means you can create a significantly nicer setup UI.
• Having an AbstractUI renderer won't be a requirement to use a core.

And also some cons:

• Unless you can find existing AbstractUI components to do it, you have to create the setup UI yourself.
• The architectural details on how you might do login/setup to get valid setting values before instantiating a core don't exist yet - we need to figure out what the best approach is.

[Arlodotexe]

Since we've received no feedback on this, we'll be moving forward with it based on our own best judgement. See issue #187