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

[BUG] - Windows Crossterm Duplicate Key Event #54

Closed
k86td opened this issue Sep 18, 2023 · 3 comments
Closed

[BUG] - Windows Crossterm Duplicate Key Event #54

k86td opened this issue Sep 18, 2023 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@k86td
Copy link

k86td commented Sep 18, 2023

Description

Crossterm will register multiple KeyPress types. In a Windows environment, I was getting twice the keypresses instead of once. It would be interesting to allow the user to target specific KeyPressKind to avoid this issue.

Steps to reproduce

Clone the repo and run the demo example from the examples folder. When pressing keys, the KeyPress message is sent 2 times (KeyEventKind::Pressed and KeyEventKind::Released). This results in the counter being incremented twice, instead of once.

Expected behaviour

The user should be able to define the KeyEventKind when listening for KeyEvent to avoid receiving twice the same KeyEvent message.

Environment

  • Windows 10
  • x86_64
  • Rust 1.69.0
  • tui-realm 1.9.0

Additional information

See this issue for reference and more information. The actual docs for the KeyEvent in crossterm are here.

Fix (?)

I think changing the struct of KeyEvent to allow to specify KeyEventKind and passing it to crossterm would work.

@k86td k86td added the bug Something isn't working label Sep 18, 2023
@strowk
Copy link

strowk commented Sep 28, 2023

This seems to also cause demo app to switch focus on Tab twice, making it impossible to activate digit counter and effectively disabling this framework for windows users.

Note recommendation from ratatui is

check KeyEvent.kind == KeyEventKind.Press
ratatui-org/ratatui#347 (comment)

The problem is that while crossterm has this "kind" field, it is lost in here:

pub struct KeyEvent {

And termion does not have that field at all (I guess it sends event only on press?):
https://docs.rs/termion/latest/termion/event/enum.Event.html

Maybe defining enum KeyEventKind with variants Unknown, Press, Release would be solution? Unknown would be field for termion and any backend that does not support the distinction, Press and Release corresponding to this -
https://docs.rs/crossterm/latest/crossterm/event/struct.KeyEvent.html

Note that crossterm docs mention that on unix the kind might also be set in case if configured:

Only set if:

Unix: KeyboardEnhancementFlags::REPORT_EVENT_TYPES has been enabled with PushKeyboardEnhancementFlags.
Windows: always

@strowk
Copy link

strowk commented Sep 28, 2023

An attempt at fix:
strowk@fa784b9

The issue with this is that it introduces back incompatibility, since all apps which were pattern matching on current KeyEvent would get error now, so strictly speaking this can only go into version 2 :(

If you run into this and need workaround, you are welcome to use my temp fix like this:

tuirealm = { git = 'https://github.com/strowk/tui-realm.git', branch = "issue-54-fix" }

@veeso
Copy link
Owner

veeso commented Oct 16, 2023

fixed 1.9.1

@veeso veeso closed this as completed Oct 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants