Closed falkTX closed 1 year ago
Can we just mask the corresponding ones out entirely? It seems like nonsense to ask whether the shift key is shift modified anyway, so an easy route to consistency is for that to never happen as far as a pugl client is concerned.
@dromer was the one that initially found the issue, so maybe he has a specific usecase for it
It's a very normal use-case: use it as a modifier key (aka: hold the key and allow for different behavior. for example -> https://github.com/Wasted-Audio/wstd-eq/blob/master/override/HeavyDPF_WSTD_EQ_UI.cpp#L128 )
The faulty behavior is easily spotted with the https://github.com/DISTRHO/dear-plugins ImGuiDemo - compared to the default desktop ImGuiDemo.
There's too many layers there I'm not familiar with to bother wading through, but it seems like anything that breaks depending on the modifier bit being set or not for a modifier key that's being pressed/release is probably doing something... questionable.
Doesn't really matter though, it should be consistently something, and the platform behaviours seem arbitrary and meaningless, so the easiest thing to do is just strip them out, always. It makes no sense to ask about whether the shift key that's currently being pressed/released is shift modified, so that's a very simple consistent thing Pugl can guarantee, and it's easy to implement for any platform.
So, fixed in 6c2a219. Tested on X11, Windows, and MacOS. Also fixed left vs right modifier detection on Windows, although that still doesn't work on MacOS.
When using a modifier flag like "shift" or "control" we have inconsistent behaviour across platforms. Mainly on X11 vs macOS and win32, that only register the modifier key after another key press.
With #110 in place, we can see the behaviour of the shift-key modifier:
Notice on how the first event the shift key is pressed, but it has no shift modifier in place yet. On key release the modifier is there.
Now on windows the following behaviour occurs:
Notice how the shift modifier is in place for the initial key press, and not present on the release event. Same happens on macOS, though I dont have the logs to confirm it right now.
Which behaviour is correct is sorta debatable, the main issue is the inconsistency across platforms.