When editing a text entry in the editor, provide the existing
macros as a clickable list to pick from. This saves going back
and forth through the documentation when editing text entries.
If the respective CAT configuration does not support a PTT
(e.g. since the rig's CAT protocol does not implement it,
and there is no DTR- or RTS-controlled hardware either),
it is possible to turn of PTT entirely yet still enable
CAT for frequency and mode control. (PTT could then be
performced e.g. via VOX.)
Using hamlib's capability reporting only reports capabilities
that are available straight through the CAT protocol of the
target rig. PTTs controlled by RTS or DTR are out-of-band
with respect to the CAT protocol, so they do not appear there.
Nevertheless, if the operator configured such a PTT type, we
assume the rig PTT can be activated which can then still be
done using rig_set_ptt().
This is supposed to automatically find the respective include
and library definitions to the build.
Just keep the previous manually defined qwt definitions for
non-MacOS builds by now.
With Qt6, those formats of QMessageBox::information() that take
non-standard label texts have been deprecated. The intention is
to always use standard texts for labels.
QMessageBox::warning():
The numeric arguments were triggering an obsolete form of the
warning dialog. Instead, omit the last "0" so it is now taken
as a supported version with overloaded button names consisting
of just one button.
The interaction between QMetaType and QVariant has changed quite
a bit between these version, thus the handling of both versions
requires some #ifdef tweaking.
By default, QSlider eats up a lot of CPU. The workaround is to
apply a stylesheet, idea taken from a stackoverflow posting.
Presumably fixed in Qt 6.3.
Instead of going back and forth through calculating numeric
values from (digit) characters and vice versa, use the original
characters directly, and just append a space afterwards.
Both referred to unsigned char in qsstv anyway.
While _BYTE still collides with the namespace rules (it's in the
implementation namespace), it appears to be accepted. "byte"
however is implemented quite differently in recent C++ standards.
Both systems are not available. Thus, Pulseaudio remains the only
usable audio system to chose (unless someone starts a real MacOS
sound support). Since there is no v4l, taking a snapshot for
transmission just does not work at all.
