It would be amazing if users who are unfamiliar with the (what seems to be to me) complicated API surrounding modifications to the editor could make their own custom editor elements as easily as they can construct user interfaces with UMG. Creating a simple method of modifying / developing new Slate content would likely make extensions for the editor explode in popularity. I feel like Unity advanced as quickly as it did because it had a fairly simple process for users to add custom editor content, leading to new features being added by the community at an astounding rate. If Epic unleashed that power on their own engine, it would likely accelerate the already impressively growing feature-set of UE4.
The problem is that the API is large and has a very complex set of underpinnings. Things like Blutilities were an attempt to simplify some of that complexity and allow users to make utility functions through blueprints that could be run at editor time but that’s of limited utility. So when the question arises of what to make simpler there’s a very large set of things to consider exposing. While in theory you could design a UI with UMG, UMG has a lot of requirements. Like, it needs a world and a GameInstance to work correctly. It has a lot of expectations of being used in a game environment, with player controller and such. The editor has no such requirement. Additionally, there’s only so much you have access to through Blueprints. You’re limited to the UObject environment. While that makes up a substantial portion of the engine, it’s far from all of it. Lots of the editor does not utilize the UObject system to manage elements and data of the editor.
Additionally the Unreal Editor is a very different environment from Unity. They only ever have one world / level context you deal with and a global selection context. Whereas in Unreal we support lots of different windows and subeditors for every imaginable asset type. There’s no universal standard for those asset editors, except for some basics for what happens when someone opens the editor for a specific asset type, who handles that…etc. So if you want to say, add a new UI, but only for UMG, and only in the UMG editor. The UMG editor would need to understand how to expose the functionality of that editor to blueprints, or whatever the simplified scripting layer/or simplified C++ layer we came up with to make it easier to extend that portion of the editor. It would need to understand how to play nice and cooperate with some arbitrary sub-editor extension.
So - what is most important to be able to extend, what’s the editing context that’s most important that you want access to…etc?
Also, i sort of assume you wanted to do all of this with blueprints. Is that the case, or do you just want to design the UI with UMG, because you find writing Slate code to be complicated?
It’s the Slate code being complicated. I would prefer modifications to the Editor to be simpler to do, even if it wasn’t with a GUI of some sort like UMG. I tried watching the initial Twitch stream that covered editor extensions and it was extremely hard to follow, simply due to the relatively large amount of API I’d have to dig through and understand before I could get what was happening. Something more streamlined where I can look at SOMETHING (GUI or code) and clearly see, “Okay, so this is my toolbar and this is how I add a new button/drop-down-menu/etc to it, and this is how I bind a function to that…” and making it easier for people to follow along with how to do more complex things like creating dynamic images like a Viewport, and whatnot.
I can understand Blueprints not really being something you can use to edit the editor interface (seeing as how Blueprints is, itself, something that is displayed from within the interface and relies on internally generated data such as the world context). I just feel like, as a user, there is an extremely high barrier of entry into fiddling around with the editor layout and capabilities that is preventing the less “hardcore”, yet still coding-experienced scripters / modders / programmers (who have trouble finding the several hours it would take just to get a sense of how the API would work) to begin expanding the Editor’s functionality.
If you COULD make modifying the Editor work similarly to UMG, then that would be absolutely incredible! But I’m feeling like that would be something rather difficult to do compared with just streamlining the code process. Still, a visual aid for the “Designer” side and a back-end on the coding side would be an extremely convenient way for people to mess with the editor and would like invigorate a rapid influx of new editor designs and abilities.
Whatever time/resources would go into it, the potential benefits would outweigh almost any loss since you would be paving the way for essentially massive crowdsourced development of the Unreal Engine.
As someone who’s dug into the editor code a fair bit without any real resources to help (aside from Michael’s old stream, which doesn’t go in depth but was an excellent overview), I’d have to agree that it really is quite complex. It took a lot of time going through editor code to reach even a basic level of familiarity with how things worked.
As Nick says though, it’s inevitable really given how flexible a framework it is. I think the only real way to do what you’re asking would be to write another layer on top that exposed a much simpler C++ interface with a very much cut-down set of features. But what would you cut out? Depending on what kind of editor extension people want to make, some would require access to certain features, while other people would need other ones. I think it would be difficult to find a balance while justifying the time needed to create and maintain the additional layer.