GUI-box steals keyboard focus

[Brainsample]

After updating from kOS 1.1.5.2, I ran into an awkward problem.
Spawning, or clicking on a GUI-box sets keyboard focus to that box.
The keyboard can only be used again by left clicking in-world first.
For some reason, a few keys like C, V and Arrows are exceptions.

=======

Test ship:

• Probe core.
• Battery.
• Scriptable control system.

Test script:

local g IS GUI(180).
set g:skin:button:width to 80.
local b1 IS g:addbutton("test").
g:show().

local keyboard_input is terminal:input:getchar().
until keyboard_input = "-"
{
	print keyboard_input.
	wait 0.0001.
	set keyboard_input to terminal:input:getchar().
}

clearguis().

Repro:

• Launch the ship, run the script.
• Use the keyboard.

Observe 1.1.5.2: All keystrokes are passed on to the world, as expected.
Observe 1.1.6.0 and later: The GUI-box has keyboard focus, all keystrokes are lost.

• Click in-world.
• Click (not drag) the GUI-box.
• Use the keyboard.

Observe: Same results.
Expected: A GUI-box only has keyboard focus when it has an active text-entry field.

[Dunbaratu]

I'm not sure there's much I can easily do about this. The GUI windows are built atop a more generic window class that controls keyboard focus and it is used for the other windows in kOS like the terminal and toolbar dialog. Having the gui NOT take focus when the others do would be odd.

[Brainsample]

Hi Dunbaratu,

There is a clear difference in behaviour between kOS 1.1.5.2 and 1.1.6.0.
1.1.5.2 works like a charm! I don't know which part of the patch is responsible.

KOS does have some knowledge about keyboard focus, apparently:
https://ksp-kos.github.io/KOS/structures/gui_widgets/style.html?highlight=keyboard%20focus#attribute:STYLE:FOCUSED
But as far as I know, there is no way to programmatically get or set keyboard focus.
So if everything else fails, maybe something like this can be added:

set GUI_box:KEYBOARD_FOCUS to false.
// ...
if TERMINAL:KEYBOARD_FOCUS
{
	// ...
}

=======

Having to reset keyboard focus manually, in the middle of a complex maneuver ... it's really cumbersome.
Even the ESC key to pause the game is out of order. :)

[Dunbaratu]

That line is not kOS choosing the focus. That's kOS telling Unity "when you think I have focus, use this theme to draw the widget instead of the normal one." It's got nothing to do with telling it WHEN to change focus - just how to draw things when UNITY says the widget got the focus.

[Brainsample]

Exactly, that line doesn't give any control over keyboard focus.

=======

There are two patches in 1.1.6.0 related to GUI:

• Made several of the string parameters to GUI widgets optional. Fixes #2290 Optional GUI parameters #2293
• GUI tooltips now implemented. the GUI tooltips apear to be broken #2414

The change in behaviour is probably caused by one of them.

[Dunbaratu]

I found which edit introduced this. It was part of PR #2403.

This isn't keyboard focus. It's Kerbal's weird home-made input lock mask system. As part of #2403, I fixed a bug where the GUI windows weren't participating in that system properly because their input locks were getting the same identity string as other input locks and they couldn't be distinguished when being removed. (i.e. the GUI window and the text terminal all had the same locking ID of "empty string" so when one got removed, they all got removed.)

It would be more accurate to say the "bug" is a design you don't like. The GUI lockout was intentional design, but in 1.1.5.2 there were bugs in how the input locking system was being used that among other things made it fail to adhere to the design. It can't merely be reverted because that same bug caused other problems and had to be fixed. The fact that all the locking IDs were getting mashed together was a big problem.

But what might work is to, now that the system works, instead of breaking it again just remove GUI windows from participating in it, leaving it only used by the terminal window and editor window.

[Dunbaratu]

^ Okay in my testing that seems to work.

I just added an option for a KOSManagedWindow to choose not to participate in the control lockout scheme, and had the GUI widgets do that, while the other ones still participate in it like normal, and it seems to give the behaviour you want without re-introducing the bugs the earlier fix got rid of.

[Brainsample]

That's good news, Dunbaratu. Thank you very much.
Only 11 extra lines of logical code, not bad at all. :D