-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
of*Window/ofEvents: pressedKeys accumulate in special cases #652
Comments
Perhaps this is obvious, but this issue ultimately stems from the fact that GLUT does not deliver stand-alone modifier keyup/keydown events like Java (or other windowing systems), making it difficult to keep track of such things ... Here is an interesting post on the topic. http://old.nabble.com/Status-of-modifier-keys-%28shift-ctrl-alt%29-td6982098.html |
is this being addressed by #807 ? |
Hi bilderbuchi -- yes that modification is on the right track, but it probably won't work as expected because glutGetModifiers() wants to be called in the keyboard_cb and keyboard_up_cb methods (at least from my testing on OSX). It will dump lots of warnings that look something like:
gameoverhack's 807 pull request would be a very useful set of methods, but instead of calling the calling glutGetModifiers() it should probably work by checking "pressedKeys" set with a call that looks like:
etc. Thus, for this to really work, there needs to be better modifier bookkeeping at the core site of the original glut callback. As I said, I'm quite interested in getting this working and am happy to tackle it. Do you know if there are any other forks addressing the issue? -- just copied some of these thoughts over to #807 |
I'm not aware of other work on that, but if gameoverhack's PR addresses at least part of the issue, I think it's best to comment there on how the PR/code could be improved. Then all the work on this kind of issue is kept in one place. PR's are there to be discussed, so don't be shy. ;-) |
I spent quite a while on this one and am beginning to wonder if it is possible to accurately keep track of keys via the pressedKeys set strategy. Ultimately the problem lies in the fact that GLUT is only delivering ascii coded values via it's keyboard callbacks. For any given physical key, these singular ascii values can be changed by modifier keys (like ctrl), meaning that in some situations (as described above ctrl+a, then release ctrl, then release a), keeping a simple list of ascii coded values will lead to unpredictable results -- basically all keyDowns are not guaranteed to have a matching keyUp. The ideal ways to keep track of pressedKeys is to have a keyEvent system that records keyboard activity based on physical keyCodes -- or at least some sense of VirtualKeys (i.e. VK_LEFT, etc). Examples include Java's KeyEvent system or a Javascript strategy like this. If we had input events at this level, it would also easily take care of issue here #807. In the mean-time, you can check out my proposed solution to keymodifier issue over at issue #807. At least it is possible to have a robust solution to that problem. |
closing this issue since GLUT is not our primary windowing system anymore. |
This is still an issue w/ GLFW |
Just tested this again. Keep an eye on the pressedKeys set.
Press CTRL-a. Then lift the CTRL and keep a held. then release a. Then you'll still have a key in the pressed keys set. To free it again, Press CTRL-a then release a, then release CTRL. |
thanks for catching this @bakercp. there are some things that have changed so much since the issues were reported that most of them are irrelevant -- but here i can see why it's still a problem. |
I'm watching your whirlwind issue cleanup session with great appreciation :) |
Out of curiosity: is this a persistent issue on ofw master? I've been using only 0.9.8 |
Hi, We are trying to clean out the many issues that we have. Can you help us by checking if this issue is still present in the latest version ? In case of inactivity, we'll close this issue by end of january, 2020. Thanks |
This is still an issue. Can reproduce with the same instructions above. |
To reproduce: ofApp:update()
{
bool is1Pressed = ofGetKeyPressed(1);
bool isCtrlPressed = ofGetKeyPressed(OF_KEY_CONTROL);
bool isAPressed = ofGetKeyPressed('a');
std::cout << is1Pressed << ", " << isCtrlPressed << ", " << isAPressed << std::endl;
} Then ... Press Then lift the then release Then you'll still have a key pressed. To free it again, Press then release |
I've finally understood the situation I've got OF_KEY_COMMAND pressed even when not pressed. |
In some cases, when modifier keys are used, the pressedKeys set will accumulate keys.
This happens because "modifier-up" messages are not sent in the same way as normal and special keys.
To test, watch the size of the pressedKeys:
Press a modifier key and a normal key -- say ctrl-a. If the 'a' is lifted first, then the modified-a key int is removed from the pressedKeys set. If CTRL is released before the 'a', then the non-modified-a key-up int is sent, and it is not erased from the pressedKeys set. If this is repeated with different modifier+key downs / ups the accumulation occurs.
Ultimately, there needs to be better handling of modifier keys. Perhaps there is a way to use the modifier masks keep track of modifier keys with a call to glutGetModifiers() in the keyboard_cb and keyboard_up_cb static methods?
It looks like progress has been made toward this in ofConstants.h
But it seems to have stopped there.
I'm happy to work on this -- any suggestions on a strategy? Perhaps this is already being addressed of 007?
The text was updated successfully, but these errors were encountered: