Skip to content
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

Mapping keys can recurse forever #38

Open
andrewfstratton opened this issue Jul 16, 2020 · 0 comments
Open

Mapping keys can recurse forever #38

andrewfstratton opened this issue Jul 16, 2020 · 0 comments

Comments

@andrewfstratton
Copy link

Firstly, the key capture works really well.

However, I am mapping keys to other keys - so if I listen for 'f' and then use java.awt.robot to (robot) type 'g', this works fine. But if I listen for 'g' and (robot) type 'f', then the events seesaw back and forth forever.

This is also an issue if you sometimes need to pass through a key event (i.e. ignore it).

Thinking about this for a (short) while, how about an option to add jkeymaster ignored key events to the event queue. This might be through a sub class of the usual key events. Then, a capture of 'f' could raise an ignorable 'g' event - when ignored, 'g' would be typed as usual, by bypassing the event handler. The 'g' capture could also generate an ignorable 'f' key event.

of course, I have no idea what is going on 'under the bonnet' - so this could be a terrible idea...

For the second case (optional pass through), I can see two other options:

  1. Allow the key listener to 'restore' a keyevent back into the event queue, so it proceeds to the next listener/s (so it doesn't get called again)..
  2. Add a Conditional Key Listener that has the option of consuming the event - or leaving it in the queue - the equivalent of setHandled(true). Again, this only helps with pass through.

For the first case, the previous options could also work for simple cases with custom code to handle the case of 'ignore events I have just raised'.

Is this something that makes sense for jkeymaster to handle?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant