EpsilonControl

Because it sent two ABBA messages out of the UART even though only one of those corresponds to an actual message (the other is the TNC control command) check-in: 71afd2125b user: luna tags: tcp-satellite-connection

This currently has multiple problems / uglinesses that should be fixed:
- The host / port inputs should only be shown if "Network" is selected from the list (GS-667)
- If the connection does not get established / gets closed, open() still reports true. I suspect that this is because QTcpSocket does not implement QIODevice all that correctly but we should probably find a workaround (GS-665)

However, everything works in principle now and you can connect to a software TNC over TCP (or to a hardware TNC that has been shared with socat, the possibilities are endless).

Also note that the TCP MTU (~1500 - some header overhead) is larger than the
largest single packet that we'll ever get and the buffers are flushed after
every full packet write so a receiver is very likely to get all bytes of a
single ABBA packet in a single TCP packet (this is not necessarily guaranteed
in 100% of cases but it will make the initial playing around with it much
easier) check-in: e1d0757d44 user: luna tags: tcp-satellite-connection

Which simplifies the code and removes duplication quite a bit. I also changed
the connect calls to use this as the context which might prevent surprises
similar to the one from a few commits ago in the future. check-in: 81b04d45d6 user: luna tags: tcp-satellite-connection

By routing the SendCommand path via a signal to the protocol instance. This
removes the need to keep a reference to it (and more importantly, the need to
check if the protocol that just got deleted actually is the protocol that we
are currently keeping track of which was a bit weird) check-in: 6c780d4642 user: luna tags: tcp-satellite-connection

This would not have happened if the removal checker was a real function and
connecting signals to lambdas that capture this is probably a bad idea for this
reason.

sender() returns (a pointer to) the QObject that emitted the signal that caused
the slot function that is currently being executed to be called. When a signal
gets connected to a lambda, things get a bit more tricky. If a lambda captures
this (in a QObject derived class), sender() is still callable. However, if the
lambda is connected to a signal with the context-less version of connect, QT
doesn't actually execute anything *on* the current object so sender() returns
whatever. E.g. consider the following code:

QObject boo();
connect(this, some_signal, [&]() { qDebug() << boo.sender(); });

Since QT has no idea that you plan to call boo.sender() in the lambda,
boo.sender() will not return anything sensible when it gets called. However,

QObject boo();
connect(this, some_signal, &boo, [&]() { qDebug() << boo.sender(); });

seems like it would work as expected check-in: 671113d62b user: luna tags: tcp-satellite-connection

And properly clean up connections once uart_selecter (sic) signals a disconnect.

This is currently mostly untested (except for checking that it compiles) check-in: 5ca6b122d5 user: luna tags: tcp-satellite-connection

Rather than a separate QSerialPort for each type of connection. From the
perspective of the satellite_connection class, it does not matter that we are
dealing with serial ports rather than anything else that can represent a byte
stream. Therefore, we only have one abstract device now and get signals to tell
us when we connect or disconnect from a certain device in a certain mode.

This isn't perfect yet, the RX path is set up in the XXXConnected callbacks but
the TX path still relies on knowing that uart_selecter_inst->connection is the
connection that we want to use. To fix this, we would need to create an
internal signal that the externally visible SendCommand emits that can be
connected to a particular transport in the XXXConnected signal. check-in: 61ae831d60 user: luna tags: tcp-satellite-connection

To make merges easier check-in: 2731fcd975 user: luna tags: trunk

user: ilya
tags: make_it_resizeable

EDITED window_widgets/address_selecter.cpp
EDITED window_widgets/address_selecter.h
EDITED window_widgets/basic_representer.cpp check-in: 06da39f0d5 user: ilya tags: make_it_resizeable

And add a settings menu entry to show it check-in: 978518ad20 user: luna tags: satellite-connection

Which is still way too coupled to the old MainWindow but it is a start. check-in: 6ab41e4f08 user: luna tags: satellite-connection

This allows us to deploy directly to the windows server check-in: e3701e5fd2 user: luna tags: trunk

This script will

1. Download and build a cross compilation toolchain (which can be pre-configured by setting MXE_ROOT)
2. Build epsiloncontrol either in the current directory when doing an out-of-tree build or into the windows subdirectory (which will be automatically created)
3. Deploy the release binary together with all needed dlls into a deploy subdirectory of the build directory check-in: 5a81e1fe50 user: luna tags: trunk

Splitting commits into semantic chunks is such a chore in fossil that I am not
going to bother. Here is the changelog where each item would have been a git
commit:

- Fixed the windows build by including dde_interface.h in mainwindow.h if building for windows
- Fix log path separators to work on windows and linux
- Fix parsing of an empty LS response in FS_manager
- Parse write response messages in FS_manager to mark the acknowledged chunks as completed
- Removed the unnecessary generated_version.h header from the dependencies
- Fixed the capitalization of the gos_commands repository
- Reduced the number of bytes that get requested with the FS_manager read button to 380
- Apparently larger messages get stuck sometimes check-in: b49fb6a44c user: luna tags: trunk

It was 250K before and as far as I know, now satellite that we are currently
integrating needs that speed. check-in: 23f811f84e user: luna tags: trunk