`MixinKeyboard` causes mod incompatibilities with Controls screen event handling

[BlayTheNinth]

Handling the screen input for resetting the selectedKey low-level inside of a Keyboard mixin results in problems with other mods trying to interact with the Controls screen using the regular means (e.g. via ScreenMouseEvents). This would most likely be resolved if amecs-api used a screen mixin (so that it would respect the loader's screen events), or used the native mod loader screen input events directly.

https://github.com/Siphalor/amecs-api/blob/cross-version/src/main/java/de/siphalor/amecs/impl/mixin/MixinKeyboard.java#L92-L100

This currently makes amecs-api incompatible with mods using KumaAPI for their key bindings (e.g. Crafting Tweaks and Inventory Essentials on 1.21.11).

[Siphalor]

Hi,

the situation is a little more annoying since we're talking abour key release events here.

There are basically three options for this:

1. the current approach used by Amecs, I agree not great for compatibility
2. more direct mixin: The annoying part here is, that key release mixins basically have to be directly on net.minecraft.client.gui.components.events.ContainerEventHandler, which is a base interface of a lot of UI widgets in the UI trees. An instanceof check here will get invoked quite often, which is probably the reason why I avoided this approach.
3. Fabric's ScreenKeyboardEvents: The main reason why Amecs doesn't make use of this, is because it only exists since around Minecraft 1.19, but Amecs supports down to 1.14.4.

I'm currently cleaning a lot of Amecs structure and old code.

Afterward, I'll probably try to implement a mix of 2 and 3, but this might take a bit until I get to it.

Out of interest: How does the compat look in general with another key modifier implementation?

While Amecs reworks a lot of the Vanilla logic, I tried to keep close to the Vanilla behavior for most methods.

[BlayTheNinth]

Out of interest: How does the compat look in general with another key modifier implementation?

I haven't noticed any other issues beyond Kuma-registered keys not being remappable (since Kuma relies on the screen events to take over remapping).

Kuma is designed to only change the behavior of keys that are explicitly registered with it; it augments them to hold their set of Kuma modifiers, and injects checks into e.g. matches, matchesMouse and isDown similar to how Amecs and Neo/Forge do. For a callback-style input handler API it sets up event listeners on loader input events to trigger when a Kuma key is used.

I could see an issue when a Kuma key somehow gets assigned an Amecs/Neo/Forge modifier since there'd be two diverging modifier configurations then, but that should be easy enough to handle in Kuma and auto-map/reset for consistent handling.