User Input in TikiTerm

Tonight I added user text-input capability to the TikiTerm widget. Note that after the input lines have been entered, they turn yellow and move above the purple output/input separator, and become interspersed with lines of output. The text entered gets added to an input buffer which asynchronous reader threads can consume lines from. (Adding stuff to the input buffer has been tested, but reading from it hasn't been tested yet.) Also, the application's stdin stream is redirected to the input buffer on startup.

Next, I need to create a worker thread that just retrieves lines from stdin (which now should come from this main COSMICi server console TikiTerm window), and sends them to the server's command handler. Hm, right now, the command handler is basically assuming it's getting commands in the form of Message objects from a LineConnection accepted by a LineCommunicator TCP server. That isn't the case for STDIO, so maybe what's called for here is to create a special subclass of LineConnection called something like StreamLineConnection, which does its I/O via an input/output pair of ordinary (quasi-TextIOBase compatible) streams, like what TikiTerm is providing us, rather than via a TCP socket. StreamLineConnection would also take over some of the functionality of LineCommReqHandler, but not all, since this type of connection isn't being created to service a connection request that came in over the network, so the whole concept of a request handler doesn't really apply in this case.

Then we need to modify MainServer and related classes (in mainserver.py) to set up a thread to read lines from the TikiTerm input buffer and bundle them up as Message objects & send them back over the main server connection from the node.

Once that's all done, we next need to modify BridgeServer and related classes (in bridge.py) so that they tie the TikiTerm input buffer back to the network bridge connection for those connections as well.

This way, the user will have the maximum number of ways to type commands to each remote node. Any of the node's active server connections (whatever subset of MAIN, AUXIO, and/or UART) will then be able to accept typed user commands. This ability will come in handy in cases where not all of these connections are able to be opened, for whatever reason. The script on my WiFi mote already is programmed to be able to accept & process input commands from any of these sources.