Keystrokes get lost
Observed under Linux (Ubuntu 20.04) with v0.8.2760: After working with GT for a while, certain keystrokes are no longer processed: arrow keys, backspace, return, control+letter. Plain character insertion still works fine. The only fix I found is to switch to a different window, then back to GT.
Inspection of the keyboard events with GTMonitor shows that the keystrokes do arrive in GT.
I'm seeing this as well from v0.8.2782 on a apple silicon Mac.
Experiencing the same problem using v1.0.1360 and Mac OS Intel.
I develop in GT daily on Mac for years and I have literally never experienced stuck keys. If I could reproduce it, we could fix it. Did you notice any pattern or do you have any hint how to reproduce it?
Is this different than the modifier key issue?
It is related to the modifier keys that get stuck.
This (or rather the closed issue 3443) happen under Windows 11 so frequently, that I've developed the habit of hitting [Win]+[Win] before using any keyboard shortcut. So for me, this is quite a quality-of-life issue.
I've distributed GT to a group of students and as an introductionary exercise had them delete a Lepiter snippet and then restore it using [Ctrl]+[Z]. For several of them, even that was enough for triggering this issue.
If any further information is needed to help fix this issue, please advise.
@zeniko would it be possible to describe the setup?
- What operating system? Windows 11?
- Are people working locally, or through virtualization?
Thanks for getting back so quickly.
- This happens on the latest Windows 11 (with all available updates applied) with the latest officially published GT builds.
- We're all working locally on our own laptops (of various brands).
@zeniko and what version of GT are you using?
IIRC, I've distributed the Windows (Intel) x64-build of v1.0.1758 from gtoolkit.com with the few changes described in https://github.com/zeniko/gt-exploration/blob/main/lepiter/akohnf1kptli27s53os0a4mvk.lepiter (in short: loading my two github repos, adding additional shortcuts for (un)indenting, hiding my home section, testing that everything works).
I've however observed this issue since I've started working with GT (in February this year) and still do with pretty every different build tested up to the recent https://dl.feenk.com/gt/GlamorousToolkit-Windows-x86_64-v1.0.1808.zip.
I've tried a fresh build from sources over the weekend, but for some reason that gets stuck when trying to load anything from the world/home screen.
One way I can reliably reproduce under Windows this is the following:
- Compile the following program which simulates the input of "→":
#include <windows.h>
INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLineA, INT nCmdShow)
{
return !SendInput(1, (INPUT[1]){
{
.type = INPUT_KEYBOARD,
.ki.wScan = 0x2192,
.ki.dwFlags = KEYEVENTF_UNICODE,
}
}, sizeof(INPUT));
}
-
Open GT in a Lepiter snippet
-
Run the executable from above in a loop and switch back to GT, e.g. by passing the following to cmd.exe (where
out.exeis the executable's filename):
FOR /L %i IN (1,1,200) DO @out.exe
This should enter a bunch of arrows into GT and [Ctrl]+[A] for selecting them or [Ctrl]+[Z] for undoing them should afterward be broken (until moving the focus to a different window and back, e.g. by doing [Win], [Win]).
There were a few changes in this space over the past couple of months. Is this still an issue?
I haven't experienced this issue for a long time already!
For me, this still happens occasionally. And the above listed steps still reliably reproduce the issue under Windows for me (tested with v1.0.2070).
I've found a simpler way to reproduce under Windows (tested with v1.0.2080):
- Start GT
- Hit Alt+Space to access the window's system menu
- Hit Esc to close the menu
Now Backspace and shortcuts using Ctrl no longer work, until the focus is moved away from GT and back.
Switching to another window and back in that situation unblocks the modifiers.
@zeniko beside that edge case, is there an issue with keystrokes in another situation?