search

oresat / CANopen-monitor

An NCurses-based TUI application for tracking activity over the CAN bus and decoding messages with provided EDS/OD files.
https://canopen-monitor.readthedocs.io/
GNU General Public License v3.0
25 stars 6 forks source link

Pane Selection not working for Ubuntu TTY #46

Closed Boneill3 closed 3 years ago

Boneill3 commented 3 years ago

Control+Up and Control+Down is not working to switch between selected panes. Scrolling within the pane is working without any issues using up, down, shift up, shift down and scrolling with the mouse.

This could have to do with the fact that I am running on a VM. I'm running an Ubuntu VM using virtual box with a windows host.

I tested with a soft keyboard within the vm to ensure that the host is not capturing the keyboard here and I had the same result.

dmitri-mcguckin commented 3 years ago

This function has been deployed and tested on multiple platforms without successful reproduction of the aforementioned bug so I am doubtful that this is a CM-specific issue.

Please try reproducing this on something other than a VM and document your findings here.

If you can't reproduce it, then I will go ahead and close this issue.

Boneill3 commented 3 years ago

So, I am still unable to use control+down even when the host OS is ubuntu, so it looks like it is not related to running in a VM. I’m going to see what values ncurses is specifically getting to look into this further.

Boneill3 commented 3 years ago

For some reason curses is reading a different value

Control+UP is read as 566 instead of the expected 567 Control+Down is read as 525 instead of the expected 526

MDC

It worked fine when using ssh to connect to the MDC from the ubuntu VM, so I tried comparing some settings.

localectl: System locale is the same, but X11 layout is US locally and n/a in MDC. Tried using a different TERM environment by launching in tmux, same thing Also confirmed TERM matches in MDC and locally

Other notes

Ran with ubuntu as host OS with different physical keyboard same result Ran on multiple VM platforms (VirtualBox on windows and Parallels on Mac)

Conclusion

So I do not know why there is this discrepancy, but accepting 525 and 566 seems like a reasonable solution.

dmitri-mcguckin commented 3 years ago

After reviewing the curses constants again, I might have come up with something that works better.

We can probably partially alleviate the incompatibility by adding the two separate keycodes together. there's no registered symbols for CTRL or ALT, but there are registered symbols for the arrow keys.

So what we could do is determine the keycode for common keys like CTRL and ALT and create our own symbols and then add that to the arrow key symbols from curses and compare input against that.

I would like to avoid having to hard code specific keycodes for specific tty setups, if possible and shoot for a platform-agnostic solution as much as possible, since that reduces the complexity.