KOS input exclusivity ignored (Clickthrough)

[JSRRosenbaum]

KSP: 1.8.1 Windows 64bit
Problem: KOS input exclusivity ignored

Mods installed:

Module Manager 4.1.3
ClickThroughBlocker 0.1.9.5
ToolbarControl 0.1.9.4
RasterPropMonitor (adopted) 0.31

KOS 1.2.1.0
Probe Control Room Recontrolled 1.2.3

Reproduction steps:

Go to Launchpad with a vehicle that has a KOS module installed.
Right Click KOS module and select open terminal
Click the terminal window to send input there
Press the 'c' key

(regular IVA switching does not ignore the input exclusivity, but PCR's does)

Log:

https://drive.google.com/open?id=19DivKYAOjlS9NHGSKaZSYRH_uZe3JQoq (Player.log)

(According to LinuxGuruGamer, who is maintaining ProbeControlRoom, The issue is with KOS needing to implement the ClickThroughBlocker Code to prevent keystrokes from falling through to other mods.)

[ngx-ree]

I second that. Although it is not a critical issue, still a bit annoying, especially when using RPM with kOS integrated.

[Dunbaratu]

It's not as simple as LGG claims, because kOS already had its own input locking system in place before clickthrublocker was a thing. Portions of that still have to exist for other reasons besides window focus, so it can't just replace the entire system with ClickThruBlocker. It will have to be some kind of hybrid. Also, kOS is NOT failing to prevent things like typing "C" from passing through to other mods. What is actually happening is that the order of events being dispatched is such that some other mods get first dibs on seeing the "C" key before kOS does.

Looking at how ClickThruBlocker works, once some mods start using it, ALL the other mods have to use it too, and this wasn't clear to me from reading its description that this is how it works. I had to look at its code on github to realize that's the problem. If you don't register your mod with ClickThruBlocker's tracking, it assumes other mods, that do use ClickThruBlocker, have permission to supercede your input events.

What may make it messy is that ClickThruBlocker's notion of what gives keyboard focus appears to be "Where is the mouse pointer right now when the keyboard key is being pressed", rather than "Where was the mouse pointer the last time the button was clicked?" In other words, it looks like it will be focus-follows-mouse, rather than click-to-focus, if I switch to using it.

I will need to spend some time experimenting with this to see if what I think from just reading the code is actually true. After I get settled in to the new apartment and can thus truly hunker down for Covid-19 isolation, I should have all the time in the world to try things out.

[ngx-ree]

Speaking for myself, it is no show-stopper issue, it's more like "nice to have". I understand there are things in kOS with much higher priority. I thought it shouldn't be so difficult to fix, since typing 'c' in kOS terminal works fine with manned ships (no cockpit switch) even without ClickThroughBlocker. Apparently it's not that simple.
Thank you for your explanation.

[Dunbaratu]

Was closed by #2729 but it didn't auto-link to it.

[Dunbaratu]

Because I had to revert PR #2729 due to needing to get a release out even though ClickThroughBlocker is needing an API change for me to use it and it doesn't look like it will be addressed soon, this isn't really closed after all. Re-opening it so it gets remembered for later.