Slate - SCompoundWidget vs SUserWidget -Explanation on implementation

Hi,

I’m just starting with slate and I have some difficulties to understand the way a new Slate class should be created.

On one side, if I inherit from SCompoundWidget, it’s pretty straight forward but if I want to follow Epicx Docs, if I create a menu screen I should inherit from SUserWidget.

But by using SUserWidget, it have a strange implementation in the cpp file :example

you need to create a class ‘impl’ with a redefinition of the New of your main class with something like :


TSharedRef<SUserWidgetExample> SUserWidgetExample::New()
{
	return MakeShareable(new SUserWidgetExampleImpl()); 
}

Why that?? because if I inherit from SCompoundWidget, I already got a TSharedRef from SNew. and SUserWidget inherit from SCompoundWidget…

I must miss something, but I can’t get it.

Thanks for your feedback.

I’ve never bothered using SUserWidget. The driving goal behind it is to enable creation of widgets that use what is called a private implementation. Instead of having the widget’s functionality be part of its public interface, it’s hidden away for itself only. It’s currently being used in different places to create subwidgets for aggregates without exposing any details of the subwidgets in their header. It’s arguably better practice and helps compilation times since the widget declaration is in a CPP file, not a header file that might be included elsewhere.

But I find it’s more trouble than it’s worth and even in Epic’s samples, using SUserWidget is the exception rather than the norm.

Thanks for the clarification.