Add multiple UI focus groups

[Faless]

Supporting split screen multiplayer is right now quite tricky when it comes to the UI.
As of the current way focus works, only one element can be focused at any given time (so player specific UI in split screen is nearly impossible).
My proposal it the following:

• allow specifying a focus group on the viewport (default empty).
• focus inside the viewport is tied to the given group (i.e. if a node grab the focus it will not affect nodes inside viewports with a different group)
• UI elements that handle ui actions (ui_*) will handle [GROUP]ui_* (eg. p1_ui_up) instead, which means when assigning new focus groups you will have to add the appropriate UI actions to the InputMap.

I have implemented this method in 2.1 (see screenshot) but before doing more work to ready it for PR (on master) I'd like to hear opinions on this proposal (especially @reduz @akien-mga and other devs).
I thought about separating focus_group and ui_action_group but I'm not sure it makes sense. Additionally we might add a function InputMap.add_group_ui_actions(String focus_group) to add all the [GROUP]ui_* actions in bulk.

Thoughts? Suggestions?

[groud]

I'm not sure about the proposed implementation, but the feature is desired.
These "groups" are hard to understand, I would consider instead adding an id to all focus related function (set to 0 by default). Then we could have a have a per control "focus filter" flags (like with the collision layers or something like that).

[Faless]

@groud can you elaborate a bit more?
Do you mean having grab_focus(int layer) or more like set_focus_layer(2) and then subsequent calls to grab_focus() release_focus() only affecting given layer?
How would you then handle UI actions (eg. deciding which focus layer will receive a given ui_up action?)

[groud]

More like, in control.cpp:

void grab_focus(int layer = 0);
void release_focus(int layer = 0);
void set_focus_mode(int mode, int layer = 0);
void has_focus(int layer = 0);

and:

void set_focus_filter(int layers_flags = 1);

And this will also need an id affected to input events, to check from which player they come from.

[nathanfranke]

I would like to use this feature for my selection system.

There is a list of buttons in a scroll container that the user can click on to select. My problem is that when they want to use tab to go to the options like "Play", "Edit", etc. the button loses focus, which deselects the button. I can work around this, but this feature would make it a ton easier for me.

[akien-mga]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

[boruok]

@Faless did you posted this issue to proposals tracker?

[Faless]

@Faless did you posted this issue to proposals tracker?

No