charmbracelet/bubbletea

Read input events instead of raw bytes in Windows (mouse support/window change events/canceling inputloop)

erikgeiser opened this issue · 4 comments

Disclaimer: This issue is meant to supersede #103 and #24. The proposed change would be based on #120. This issue is based on a comment I made in #103.

Windows supports reading INPUT_RECORDs with ReadConsoleInput. However, this means that the Windows input event parsing logic (which would then be based on INPUT_RECORD structs) would have to be decoupled from the Unix logic.

Changing the input handling to use INPUT_RECORDs would allow bubbletea to receive MOUSE_EVENT_RECORDS (closing #103). It also enables the usage of PeekConsoleInput to augments the WaitForMultipleObjects mechanism introduced in #120 in order to solve #24 for the Windows Terminal where #120 does not work reliably.

INPUT_RECORD can also be a WINDOW_BUFFER_SIZE_EVENT which sounds like a good replacement for SIGWINCH on Windows.

There is also already a PR for the Go standard library to add ReadConsoleInput but it has become a bit stale over the last few months. However, we probably need PeekConsoleInput to augments the WaitForMultipleObjects anyway so the implementation has to use windows.NewLazySystemDLL("kernel32.dll").NewProc("...").Call(...) anyway.

After some experimentation I found that it is easily possible to get both mouse events as well as window change events using ReadConsoleInput. However the Go standard library does not help much with that so it is necessary to write a lot of glue code to interface with the Windows API functions.

Good news is I already did just that over at https://github.com/erikgeiser/coninput/ (see also the documentation and the example).

Any news on this? It would be pretty cool, if windows input events get handled properly

It’s going to be a little bit until we can look into this this one, but it’s definitely something we’re keen to sort out. Ideally, Erik’s library makes this a breeze.

Just some housekeeping here: closing this as #140 is now closed. Erik's, thanks again for all your work around this regardless.