Yes that’s correct, what you said about the second option.
The following setup uses the game input mode and these three events to control an active widget. By default you cannot control widgets while the input mode is set to game only without additional setup.
Inside the widget blueprint I created three custom events:
These are the target events I want to call with my input events, which are handled like this inside the player blueprint:
Bear in mind though you have to make sure you actually can forward them, as in the widget exists and you’re currently in a dialog. And if you’re not currently in a dialog you don’t forward that input at all, a simple branch statement should do the trick (which I forgot in this example).
As with what I meant by capturing the player cursor, by default if you use the game and ui input mode the mouse x, and mouse y events get consumed before they reach the player in the input stack, except if the cursor gets captured, in which case the input gets received by the player (by default you can hold the left mouse button down, while in game and ui input mode, and you can look around again).