Been going through the engine source to determine how to add 1 extra context menu item to a USplineComponent. Found the FComponentVisualizer system. Currently (4.10) it seems like the idea is that you would write your own subclass of FComponentVisualizer, but not any of the existing subclasses, such as FSplineComponentVisualizer in my case. All of the existing FComponentVisualizer class headers live under “Engine\Source\Editor\ComponentVisualizers\Private” and are not exposed through the module’s public api.
Now I can edit the engine source and add “COMPONENTVISUALIZERS_API” to “class COMPONENTVISUALIZERS_API FSplineComponentVisualizer : public FComponentVisualizer” and then create my own subclass in my own plugin module and it works OK.
The issue though is the current design of these classes assumes no one will subclass them. If we look at “TSharedPtr<SWidget> FSplineComponentVisualizer::GenerateContextMenu() const”, we see that it uses FMenuBuilder object on the stack, adds some things to it, and then creates a widget from stack memory and then returns the new widget. I can override this function and tell it to call the super version, but I’ll only end up with the widget, rather than the “FMenuBuilder” object which I would like to add on to.
Wanted to gauge the community’s thoughts on the current design and potential improvements. It may make sense to inject some virtual function calls into the GenerateContextMenu() pipeline so that it would allow for subclass customization (e.g. a virtual function with a FMenuBuilder reference). The primary end goal being: make it easy for plugins to extend current behavior.
The first step though would be opening up existing subclasses of FComponentVisualizer to be publicly exposed, and change their design assumption from “no subclasses” to “subclasses allowed”. Thoughts?