Feature: Add custom serial buttons extension

[sevimuelli]

Adds a new extension for creating buttons to send custom commands.

Addresses discussion 101, 134, Pull request 324 and Issue 267.

Mostly used to control an external KVM so one can switch ports inside the JetKVM, but I tried to keep it as universal as possible. Would probably also work with your Serial Console Adapter. Everything is tested and all automated test passed. As it looks like many people are using the serial port to control or connect external devices, this extension could help a lot of users. Here are some screenshots:

Basic view:

Serial settings menu:

Button config menu:

Response view:

[CLAassistant]

All committers have signed the CLA.

[IDisposable]

Code review pending, but one design suggestion. The line-ending should probably be set in each step (not globally) and be None, CR \r, LF \n, or CR/LF \r\n... that way each button can send exactly as desired instead of forcing a line-ending to be sent and forcing them all to be the same.

[sevimuelli]

Code review pending, but one design suggestion. The line-ending should probably be set in each step (not globally) and be None, CR \r, LF \n, or CR/LF \r\n... that way each button can send exactly as desired instead of forcing a line-ending to be sent and forcing them all to be the same.

Yes, I can do that change. Especially to include separate CR and LF. The reason why I made the setting global and not for each button individually is because it is highly unlikely if not impossible to have more than one client device. And I believed that one device always uses the same settings. But it's an easy change so I will adapt it. 👌

[IDisposable]

The reason why I made the setting global and not for each button individually is because it is highly unlikely if not impossible to have more than one client device.

Indeed if what you're doing it emitting to a serial-controlled KVM... but this extension is SO MUCH more useful than just that... any serial connection could be driven, so very easily could create macro/buttons for a whole bunch of common commands or snippets that you might want to emit... like "start a command", [user then types into the terminal], "emit some config stuff" , [user types some more, "end the command setup" (which would have the terminator selected to something)

[sevimuelli]

I completely agree. I think the best step would be to merge the two extensions and create a propper, highly functional and universal serial extension. I already did most of the suggested changes but some are still missing.

To-Do:

• Remove base64
• Implement formalization (formatControlChars)
• Implement proper pause functionality

One thing I noticed about the serial console extension, I don't know if it's a ME problem or a general problem, is that if I click open console, I can click in the console but can't write anything. Is there maybe a problem that the port is not available? Looking at serial.go, it should be ok. I need to do some more troubleshooting.

I'm thinking about how to best combine the buttons and the serial console. Like if you press a button to send a command, should the send command also appear in the console, should the response appear in the response window i created or in the console or both, or don't we even need my response window? I agree that the best step is to combine the two extensions but I want everything to work properly together and avoid redundant functionality or things working against each other.

[IDisposable]

One thing I noticed about the serial console extension, I don't know if it's a ME problem or a general problem, is that if I click open console, I can click in the console but can't write anything. Is there maybe a problem that the port is not available? Looking at serial.go, it should be ok. I need to do some more troubleshooting.

To be clear here... when you are in the serial console, the keys you press are sent out the serial point so unless the remote echoes them back, you will see NOTHING.

What is shown in the serial console is what the remote device is sending... it could have absolutely nothing to do with what you're typing, if anything...

Imagine that your serial port is connected to an traffic signal control port, you might just get EASTBOUND YELLOW WESTBOUND YELLOW EASTBOUND RED WESTBOUNT LEFT GREEN etc... and if you pressed the N key that might trigger right-of-way process to switch to Northbound getting the green :)

[IDisposable]

I'm thinking about how to best combine the buttons and the serial console. Like if you press a button to send a command, should the send command also appear in the console, should the response appear in the response window i created or in the console or both, or don't we even need my response window?

Assuming there are two distinct regions, pressing key OR pressing a macro button should send the bytes out the serial port (and show them in the "SENT" region).

The "RECV" console region should only show what is received from the attached serial device. If it chooses to echo back what was sent to it... ONLY THEN would the console "RECV" region show anything, and what it show could be completely distinct from what the device sent.

[sevimuelli]

First, thanks for clarifying. Now i get it! 😅
About the distinct send and receive region, what if we would only use one window, the existing serial console we already have? One could have an option for "local echo" or something, like many terminals or serial apps support it, that the things you write are echoed back into the terminal. I think this would also make it easier to follow the flow of signals instead of two distinct regions.

So I'm proposing to following:

• Merge the two extensions
• Modify the existing serial window, have an option to echo commands that are typed or sent by buttons
• Remove my "response window", as it is redundant
• Still implement formalization
• Implement a proper pause functionality, the way you proposed it. So messages don't get lost but temporarily stored in a buffer

What do you think about that? Maybe you have other great improvements I could implement while I'm on it?

[IDisposable]

Perfect! Just a little checkbox for the local echo

[IDisposable]

Looking much nicer. Are you still planning on Play/Pause ?

[sevimuelli]

Still a work in progress. Frontend is finished more or less. Now working on properly combining the data from the serial terminal and the buttons and routing all traffic including local echo to the console, with normalization. Just wanted to make a commit for the progress so far. But I was waking up with my Laptop still on top of me in the middle of the night, so...

I will finish the backend and then make a commit. About the pause functionality, I'm not sure if it's actually needed. I was planning on omitting it. What do you think?

[IDisposable]

I think we can ship without pause, it's a nice to have, but not required.

[sevimuelli]

Still a work in progress. I just had to commit to update some things. Final version should be done later today

[sevimuelli]

Now everything looks fine and seems to work. I added some options to configure normalization and also added a pause button in the terminal. The last thing I want to do is some real world testing, connecting my USB-to-RS232 adapter and simulating some things.

The only thing I looked at but couldn't figure out how to fix it is the issue with the focus of the terminal. When you open the terminal and then open a popover, you can't use the terminal anymore and have to close and reopen it. It has to do with this focus trap. Would be amazing if this can be fixed.

[IDisposable]

Sounds like the modal is NOT disabling the keyboard trap.