I propose that the UserWidget base class should have a method called GetNamedSlot that returns a named slot provided a slot name if it exists.
This change would allow the insertion of widgets in other widgets programmatically without requiring full knowledge of the widget hosting the new child widget. This can be useful in design patterns where, for instance, you want to be able to swap out HUD classes entirely, but still have widgets inserted into these HUD classes, without having hard references to every HUD class and without having to create a common user widget base class, as user widget blueprint inheritance is not something that is greatly supported; although it does work for most things.
It has functions for setting and getting the content for named slots. I have no plans to return the actual UNamedSlot, they’re just an implementation detail, and I don’t intend to allow direct access.
Ah, getting and setting content would be just as nice. I didn’t look into the source code, was looking at it from a purely blueprint perspective but you’re right that functionality does exist. Is there any reason that functionality isn’t exposed to blueprints?
I could, but I’d prefer not to. They are mostly a designer concept. I had to expose them in C++, but from an API design they’re not ideal. Right now if you rename a slot, it breaks stuff, but I had actually planned to fix that so that it stored a GUID and the name was just a name.
What I’m afraid of is a lot of folks writing code that looks like magic, setting slot content and they just happen to know the slot names. I don’t want to encourage that use case.
What I would prefer someone does is make a function on their user widget that’s “Set SlotName Widget”. That way it’s not really magic, and if the name changed in the future, the users on the team would be insulated, since it’s not just a string, but instead some compiled function they’re calling.