Hi, further brief comments in blue inline
New one to add this morning - I get a warning from either W10 or Norton
that "Wide Graph is using your microphone" The radio audio is on
line-in... Probably nothing to do with WSJT-X?
Alan G0TLK
On 23/05/2020 17:36, Bill Somerville wrote:
Hi Alan,
thanks for your considered comments and observations. Some comments in
line below from me.
On 23/05/2020 16:50, Alan Groups wrote:
Hi, I'm concentrating on the UI rather than program function,
hopefully not too pernickety! Some of these may not be specific to
RC1 but are just things I've noticed on specifically looking for
anomalies etc:
1. The RC opens in 7 seconds on this machine, 5 seconds for 2.1.2 - a
noticeable difference?
This is probably due the the size of the CTY.DAT file, which is loaded
synchronously at present. We could load it in the background while
proceeding with decoding if users feel that one-time delay is too
long, but there will be cons such as decode highlighting and DXCC
Entity assignment etc. not necessarily being applied to the first few
decodes, also any extra complexity introduces potential defects.
My (admittedly middle-aged) system doesn't have a CTY.DAT file (or at
least not that my deep search engine can find!)
2. In the RC if I click on the Menu's box to clear it the UI jumps to
top left of my screen, much reduced in size, and with about half of
the title bar off screen. Screen here uses W10 scaling. Incidentally
same happens on 2.1.2 but I can't say I've noticed it before.
I'm not sure what you mean by "the Menu's box to clear it",
Menu box normally ticked, click on it to remove the tick
what you observe may be due to using the 32-bit version on v2.1.2
which has a minor incompatibility in the way that window positions and
sizes are stored between sessions. Switching between a version that
uses the old format (32-bit Windows v2.1.2 or earlier) and any v2.2.0
version will yield to inconsistent window sizing and positioning on
start up.
Noted, and that probably explains the paragraph below, but I don't
understand why turning the menus off in the 64 bit RC1 should cause a
major UI window size change?
If I let it do that on the RC and then close it, then the 2.1.2
instance when started has the screen identically sized small and
placed top left. (The RC1 and 2.1.2 are in separate folders) but then
if I correct the 2.1.2 instance back to my larger UI panel and close
that then RC1 still starts with the same small screen top left.
Ditto.
The Wide Graph is unchanged.
Clicking on the menu box again in RC1 when it's back to my larger
size to bring the menus back behaves as expected - the menu bar
appears, no change in UI size.
3. In RC1 in yesterday's session I called a station but they didn't
reply (at all).
The standard messages and lookup etc fields are still populated with
that failed QSO information in today's new session (I haven't
transmitted today). Should these fields perhaps be cleared on
program start?
We recommend that you hit the ESC key when abandoning a QSO, this will
clear down the DX Call, DX Grid and messages. This is important also
if you are using the AP decoding facility.
Noted
If in today's session I click "Log QSO" then a log entry for that
failed QSO appears even though a QSO has not been completed with RR73
(see other thread). I called that station yesterday but the log
entry has today's date and time.
The log QSO button will allow you to log a QSO based on current UI
information.The start time of a prior QSO is not carried over from a
previous session as it makes little sense in most cases. It is your
responsibility to ensure that the data logged when logging a QSO is
correct.
Yes, and in normal use rather than bug hunting the data would probably
have been overwritten, but couldn't the program make sure these fields
are cleared on startup to make it more intuitive?
4. "Stop" button when clicked doesn't change colour to show
monitoring is stopped by that button, although "Monitor" button does
change from green to grey. Stop button seems redundant as Monitor is
a toggle? Probably should be one or the other either Stop and Go
buttons, or just the Monitor toggle?
The "Stop" button also stops the automated playback of saved .WAV
files so it is not exactly the inverse function of the "Monitor" button.
Noted, but from a UI usability perspective control duplication,
particularly with slight differences, can lead to user confusion.
5. Pulling the red Tx marker moves it so the left edge sticks where
the cross cursor is shown. Seems a bit odd if one has picked it up
in it's centre or RHS to move it? Once one has realised what's
happening it's OK, but appears out of sync until then?
WSJT-X defines the Tx and Rx audio offsets in terms of the lowest
frequency of a signal. The ability to move the Tx and Rx frequencies
by clicking the waterfall is consistent with that protocol.
Yes, but it looks odd and again a bit unintuitive. Fattening the LH
"upright" of the marker (or similar visual enhancement) would maybe
assist that and reinforce the protocol? Example attached.
Green cursor does the same.
Maybe make the LH edge a bit fatter or something, to indicate that as
the preferred cursor pick up point?
On first test I pulled the cursor left but the TX marker went to the
right, but I haven't been able to repeat that.
6. On the wide graph should the sliders have names and not just
tooltips, for accessibility?
Screen readers will announce the tool-tips. We would prefer to keep
the Wide Graph and Fast Graph controls compact.
Noted
7. Darker green Rx cursor noted and the reasons for it, but tight
against the palette black background it's not so visible as the
lighter green. Maybe a white line is needed between scale and waterfall?
Some more changes to that rendering have been made for the next
release, hopefully we are homing in on something that works for everyone.
Great
8. I installed the RC in a separate folder to 2.1.2 but must admit
to being a bit surprised that it picked up all my 2.1.2 settings?
We treat the Settings as user owned content. Settings are associated
with a "--rig-name" command line argument. For most that means the
default unspecified '--rig-name'. We feel that carrying over settings
automatically when upgrading, for each and every instance the user may
have set up is more useful than starting with fresh settings for every
installation.
Noted, but it has had me a bit baffled when trying to run two instances,
although maybe I should have checked for instructions first!
Hopefully the above is of some use, keep up the good work!
Alan G0TLK
73
Bill
G4WJS.
On 22/05/2020 18:05, Alan Groups wrote:
Hi, just tried this out on some 10m Es using FT8:
I find the two stage display of decodes a little disconcerting; the
double flash of the decode button doesn't help - adds more visual
clutter? Could the user maybe have a choice to temporarily cache
the early decodes and then show them all at once along with the
later decodes?
"The Status bar now displays the number of decodes found in the most
recent Rx sequence" - this needs a box to say what it is on mouse
hover, or maybe simpler to say "Rx decodes: xx" rather than just "xx".
Compared to 2.1.2 there are definitely more decodes in the band
activity box.
Not a specific 2.2 RC1 comment but generally would be nice if "Tune"
could use a CAT code to reduce rig power output if the user wanted -
useful for auto-ATU's. Even better if that could happen
automatically on band change should the user want it!
Alan G0TLK
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
