Allow to explicitly disable focus release on specific Controls

[Spartan322]

Describe the project you are working on: Simple Space-centric RTS

Describe the problem or limitation you are having in your project: The auto-managed Focus Next, Prev, and Neighbors implementations can't be disabled, causing QoL issues with some of my UIs. (least without the cost of an even more complicated SceneTree, godotengine/godot#35045 incidentally related but not isolated)

Describe how this feature / enhancement will help you overcome this problem or limitation: Giving choice over whether I desire the ability for Godot to auto-manage the focus changes would allow me to be more direct with my UI's Tree.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work: I'm not certain on a clean manner to do this, I'd prefer to discuss avenues to solving the problem foremost, so I can't.

Describe implementation detail for your proposal (in code), if possible: As stated, I'm not certain on a nice clean implementation, though my current naive ideal would be to have an enable/disable tickbox for the Focus Next, Prev, and Neighbors separately from the focus_mode.

If this enhancement will not be used often, can it be worked around with a few lines of script?: No, the only alternative is disabling the focus altogether, which for inputs is useless. (and thanks to godotengine/godot#35045 its impossible with RichTextLabel having selection_enabled)

Is there a reason why this should be core and not an add-on in the asset library?: I don't believe it really can be done as an add-on, least not efficiently, its an automated oversight for how Focus is implemented in engine in my opinion.

Edit: It seems there is a manner of doing so, but it sounds more like a hack then intended, setting the Focus Next, Prev, and Neighbors to the path of '.' which I suppose works fine, but it be nice to be able to more directly disable this functionality in editor.

[groud]

In the InputMap settings, you can also remove all default shortcuts for the ui_* shortcuts. That should disable the default focus changing. I am not sure it is worth implementing a setting to disable this, it's not a very common use case, being able to remove the shortcuts might be enough.

[Spartan322]

In the InputMap settings, you can also remove all default shortcuts for the ui_* shortcuts. That should disable the default focus changing. I am not sure it is worth implementing a setting to disable this, it's not a very common use case, being able to remove the shortcuts might be enough.

First I don't want to disable the ability to change focus globally, secondly I don't want to be screwing with InputMap to correct my issues with auto-managed focusing, (specifically since preventing focus changing is an oversight of a UI system, there are just as many valid cases for not doing it, and I'm honestly a bit hard pressed to see a good justification automating it like this tbh given there are plenty of cases where similar things don't end up automated) preferably I'd like the ability to either locally or globally disable auto-managed focusing. (I'd prefer locally disabling it, but even globally doing so is fine with me as long as its not permanently disabling manual management of focus changing) Removing the ui focus buttons is actually imo a worse solution then hacking out the focus by setting them to NodePath(".") which I already don't want to do because its still running the focus management in the background, I'm just telling it to change the focus to the same thing its already focused on. If I want say a LineEdit Control with the ability to press up or down keys for some reason (like with a console with a history I could move back through) and there are surrounding Controls that I have or want focusable but don't want to shift focus from the LineEdit alone, I am required to bodge the focus system. And I wasn't even originally aware that I could bodge it in that way.

[groud]

If I want say a LineEdit Control with the ability to press up or down keys for some reason (like with a console with a history I could move back through) and there are surrounding Controls that I have or want focusable but don't want to shift focus from the LineEdit alone, I am required to bodge the focus system. And I wasn't even originally aware that I could bodge it in that way.

If the matter is just to be able to handle the event before the focus system does, you simply have to override the _input() method and mark the event as accepted (via SceneTree.set_input_as_handled()). This is actually the correct solution to solve the problem.

[Spartan322]

If the matter is just to be able to handle the event before the focus system does, you simply have to override the _input() method and mark the event as accepted (via SceneTree.set_input_as_handled()). This is actually the correct solution to solve the problem.

Then that incidentally solves the problem, (as I happen to already desire to implement an _input method in that case) it still stands as an oversight, not every case is something I see as beneficial to implement an _input method just to cancel the focus system, some of the buttons I have I want to be focusable, but don't want to leak into another button, or other input options where I don't want to change the focus by pressing control keys, (and am merely reading the input otherwise) in which case outside of accepting the event (which I'm either not always capable of or would prefer not to do so for possible special cases, or it simply wouldn't work) I'd need to wire the focus system strangely. (as in self-directing it to do so) Even in that case I'm still hacking the engine in a manner that completely nullifies the focus system, in which no way that could be reasoned by someone looking only in the editor. (even with the hack I suggested its not actually immediately obvious, but it isn't hard to figure out) Personally I don't get why the system had to be automated, but in the least if it is gonna be, it appears to me an oversight not to be capable of disabling it somewhere.

[DaGamingWolf]

a little late to the party, but for the sake of those who come across this later, you can create an array to manage "focus layers," and use group call methods to toggle focus on and off depending on any circumstances you want, so if you want focus not to bleed into another button, ensure that button's focus mode is off when conditions are met for that circumstance. this could make it easier to manage large groups of focusable objects, as you could use something like the Q key to switch between focus layers, then tab through the items in the layer.

It does seem like something that would best be implemented natively in godot, though. there are too many circumstances where this could be useful, and it'd help the game be more accessible to the visually impaired.