-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tab duplicity #52
Comments
would |
Kinda works. All other keys get detected immediately, but tab enters the monitor only after several presses. Doesn't seem to be a timing thing. Quite peculiar.
|
might have something to do with repeat key events (just shooting in the dark) |
I doubt it, it's reproducible way over the threshold. Just holding it down of course get the results faster. |
it looks like the event monitor stuff at the bottom of |
not so simple, since then it eats up all input and you can't get past the first screen. :) |
wait why not? the monitors don't (shouldn't) eat events:
it is just invoking them. the problem is that hot key code runs before it and that does cause a return before the monitors run. |
oh, but apparently |
maybe |
I'll try it tomorrow; please fix the opcodes before you forget. |
yeah, that does it nicely. It now triggers also out of gc for some reason, but that's nothing to lose sleep over. |
heh, some might say that is a feature :) I think if we cared we would have to do go back to using a hot key and have the I'll open an issue for the opcodes, I wont be back in town until Monday. |
tab is used for two things:
the first we do in the wm via a hotkey, the other in gc manually. So the hp display never shows up, because the wm eats the event, It can only be achieved because the code is not strict — by using ctrl-tab or other mod keys.
It sounds awkward to check for the gc in WindowManager::HotKey, so I'm looking for ideas.
The text was updated successfully, but these errors were encountered: