My 2 cents ... there has been an issue with some 'developers' (and I use
the term loosely) creating a way to get around the requirements that an
operator must be in front of the rig when in operation; thus creating an
automatic QSO machine.   This differs from beacons, as we all know, as
it is a TWO way communication.

This completely violates a number of regulations both in the US, as well
as other countries, yet you have people offering these 'routines' on a
few sites, and even on eBay.

How do you stop such obvious flouting of the regulations, as well as the
original intent of the developers to make a user-friendly way to make
contacts when conditions are dreadful:    >>> You don't make it easy for
the 'developers' who do not follow the rules.   <<<

I've done about 30 or 40 QSOs now with v2.1.0-RC5, both FT4 and FT8 and
have not had a problem finding the OK button to log that QSO.   I
realize that those with limitations need to have some consistency, but
that can be overcome in time by working with the developers offline.    
However, the constant complaints about the location of the buttons is
taking up bandwidth that could be used to take care of more pressing
issues with the beta.

Neil, KN3ILZ

On 4/30/2019 1:13 PM, WB5JJJ wrote:
My vote is with Steve on restoring consistent button positions as
well, even though I can easily read and locate the OK button.  It does
take extra time plus "muscle memory" is of no value in this,
especially with the 6 second turn around now.  Streamlining the
process should be paramount.

My reasoning:

In the early days of WSJTx, there was no integration with HRD LB for
logging of FT8, MSK144 or whatever mode contacts.  I solved this with
an auto-bot program where a double mouse click on a shortcut would
start the automatic process to find the WSJTx log adi file and import
it into HRD LB in a matter of seconds with no further interaction on
my part.  It worked great since there was not any other option except
doing it manually every time.

The way I set up the program was using XY positions, which worked. 
But as WSJTx evolved, I periodically had to make subtle changes to
these locations. I took the easy road, even though the program would
look for changes in color text or background and even text itself. Of
course all of that is now in the past as both WSJTx and JTAlert take
care of logging to HRD LB instantly.  The program has long since been
abandoned.

So, the randomness of the OK and CANCEL are a moot point as I'm sure
the auto-bot technology is even better today than several years ago. 
Putting the burden on the masses to attempt to defeat those few that
try to automate the process is virtually impossible.

WB5JJJ - George


---
This email has been checked for viruses by AVG.
https://www.avg.com
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to