Windows Compatibility

[Tired-Fox]

Windows ASCII API: Windows ASCII API
Seems like the Windows ASCII API is the same as what it would be on Linux.

Additions:

• SetConsoleMode
• Better terminal experience for windows

[Tired-Fox]

Looks like the console mode will need to be changed to get mouse input. Also could help with the clearing of the buffer and overall terminal experience.

References:

• Change mode
• Windows ASCII API
• Different modes

[Tired-Fox]

This may not be needed if pywin32 is used to get mouse input.

Going to try some things out while referencing this from StackOverflow

[Tired-Fox]

Overall, mouse actions, such as clicking, are fairly easy to retrieve. However, mouse position on the terminal is hard to do, hence why not many python libraries integrate this.

For windows it may just be optimizations with no mouse interaction unless inside of WSL or MSYS2 where mouse actions work out of the box.

[bczsalba]

That has been my idea as well, as Windows Terminal seems to be trending toward proper xterm support as of recent.

[Tired-Fox]

@bczsalba
It's been a while since I contributed, but I have learned a lot about the Win32 API. I know how mouse input, keyboard input, and window resizing can be implemented for windows.

It would involve using custom built windows API wrappers. The main WinAPI method to use would be ReadConsoleInput to read all the events from the standard input. I would be able to write a class/api based on this example. It would need to replace what is being used for input events if the user is on windows.

The API would include features that can be hooked into. The hooks would include:

• Mouse Move
• Mouse Input
  • Left
  • Right
  • Middle
  • Wheel
  • Horizontal Wheel
• Keyboard Input
  • Keys
  • Chords
• Screen Resize

My idea is that I could create a thread that writes to a thread safe structure that holds a flag for screen resize and mouse move along with current screen size and mouse position. It would also hold a buffer of keyboard/mouse inputs that then can be read by whatever is reading the inputs.

Let me know if you are interested in pursuing this!

[Tired-Fox]

Alternatively, there are some console modes that can be set, through the Win32 API, that can make the mouse events, and key events, get printed to stdin. This would allow the current pytermgui code to read mouse input. Below I have posted an example based on pytermgui's current way of handling windows keys. If you run it, it will print out all events found. The example uses a context manager to set the console settings then reset the settings when input is no longer being read.

Example source from my gist. Below is a GIF of it working including mouse events.

[bczsalba]

Sorry for not replying earlier, I had a super busy couple of weeks! I really like the second approach; it seems a lot easier to implement into the system, so long as there are no obvious drawbacks. I'd say go for it, it would be massive to have!

[Tired-Fox]

From what I see there are no drawbacks. Just tells windows to take the events that it is already sending and input it as ansii codes. Should work on most if not all windows versions.

I will work on implementing this into the library in a few hours.