The "developers" who don't follow the rules can figure out how to build the package where this feature is turned off quite easily - the instructions on what you need to build WSJT-X from sources is as easy as the sources are to come by. There have already been complaints about things like this from the accessibility community. Making things harder on 99+% of users to try (and somewhat fail to) fix the problem isn't the solution, especially because the rule breakers will take the time needed to build the package with the offending lines modified, as there are already source patches available online.
Adam N5YHF On Tue, Apr 30, 2019 at 1:53 PM Neil Zampella <ne...@techie.com> wrote: > 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 > > > > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free. > www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > <#m_310810965809785766_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > 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
