The Status(1) message acquires the new fields Frequency Tolerance, T/R
Period, and Configuration Name. The Rx DF, Tx DF fields become
unsigned (this should be a benign change which is just for correctness
as -ve values have never been possible).
The Close(6) message becomes bi-directional allowing external
applications to gracefully close down WSJT-X instances.
A new message SwitchConfiguration(14) is provided that allows an
external application to switch the current configuration of a WSJT-X
instance.
Another new message Configure(15) is provided to allow external
applications to adjust some key parameters like the mode and submode.
See the NetworkMessages.hpp header commentary for full details. The
UDPExamples/MessageAggregator reference application has been updated
to be able to exercise all of the above changes.
Note that this commit enforces stricter checking on the
"Settings->Reporting->Allow UDP requests" option, which must be
checked before any state changing incoming messages to a WSJT-X
instance are processed.
This change may break N1MM Logger+ integration, notably the CLASS ADIF
field is populated which may not be recognized by N1MM Logger+, nor
interfaces to it.
One exception to ADIF conformance is that the ARRL_SECT field may be
populated with the value DX despite it not being a valid ARRL_SECT
enumeration value. This is done for consistency with N1MM Logger+ ADIF
exports.
Divide DT search range into 3 segments. Search central segment (near DT=0)
first and try to decode the largest peak. Then find the largest peak in each
of the surrounding segments and try to decode those only if the peak is larger
than the one found in the central segment.
Also re-indent ft4_decode.f90 and some other minor tweaks.
The Status(1) message also acquires the current configuration name as
a new field. See NetworkMessage.hpp for details. The UDP reference
example program message_aggregator acquires the ability to display and
change the configuration of a WSJT-X client to exercise these new
features.
Re-enabling the WSJT-X i18n facilities. This allows translation files
to be created for languages that are automatically used to lookup
translatable strings. To enable a new language the language name must
be added to the CMakeLists.txt LANGUAGES list variable in BCP47 format
(i.e. en_US, en_GB, pt_PT, ...). Do one build with the CMake option
UPDATE_TRANSLATIONS enabled (do not leave it enabled as there is a
danger of loosing existing translated texts), that will create a fresh
translations/wsjtx_<lang>.ts file which should be immediately checked
in with the CMakeLists.txt change. The .ts should then be updated by
the translator using the Qt Linguist tool to add translations. Check
in the updated .ts file to complete the initial translation process
for that language.
To aid translators their WIP .ts file may be tested by releasing
(using the lrelease tool or from the Linguist menu) a .qm file and
placing that .qm file in the current directory before starting
WSJT-X. The translations will be used if the system locale matches the
file name. If the system locale does not match the file name; the
language may be overridden by setting the LANG environment variable.
For example if a wsjtx_pt_PT.qm file is in the current directory
WSJT-X will use it for translation lookups, regardless of the current
system locale setting, if the LANG variable is set to pt_PT or pt-PT.
On MS Windows from a command prompt:
set LANG=pt_PT
C:\WSJT\wsjtx\bin\wsjtx
elsewhere:
LANG=pt_PT wsjtx
