Re: [wsjt-devel] Bugies in 2.1.0
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 and "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 On Tue, Apr 30, 2019 at 9:15 AM Steve Huston wrote: > On Tue, Apr 30, 2019 at 3:01 AM Christoph Berg wrote: > > Re: Bill Somerville 2019-04-29 < > af407b47-deae-ab9a-bf8e-5d638b1bf...@classdesign.com> > > > not disagreeing but there are reasons for this that I can't reveal. > Let's > > > just say it is to deter LIDs. Sorry. > > If the idea is to make people think before logging, I'd say this > > feature will merely induce stress that makes them focus on the > > buttons, and even less on the actual log. > > If the idea is to defeat automated operation, there are lots of tools > > that can identify and click buttons in GUI applications. > > https://stackoverflow.com/questions/4129430/qt-automated-testing > > Please don't put that burden on everyone. Or at least be open and > > reveal the reasoning. > > No, simply don't put this burden on people. UIs are a standard for a > reason. This will not deter automation at all, it will simply make > the people doing the automation either use smarter automation tools > instead of "click this many pixels in from the right and this many > pixels up from the bottom" to "click the button labeled 'OK', 'Ok', > 'ok', 'Enter', 'Log', etc" > > What this will do, and already has done based on some of the emails > I've read here, is cause people to click the wrong button because it > was literally there 45 seconds ago and miss logging a contact. Or > they will look into the code, find the part that does this, and remove > or disable it. > > I realize it may not be up for a vote, but I vote an extremely strong > no on this one. > > -- > > Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci > Princeton University |ICBM Address: 40.346344 -74.652242 > 345 Lewis Library |"On my ship, the Rocinante, wheeling through > Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, > (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' > > > ___ > 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
Re: [wsjt-devel] Bugies in 2.1.0
On Tue, Apr 30, 2019 at 3:01 AM Christoph Berg wrote: > Re: Bill Somerville 2019-04-29 > > > not disagreeing but there are reasons for this that I can't reveal. Let's > > just say it is to deter LIDs. Sorry. > If the idea is to make people think before logging, I'd say this > feature will merely induce stress that makes them focus on the > buttons, and even less on the actual log. > If the idea is to defeat automated operation, there are lots of tools > that can identify and click buttons in GUI applications. > https://stackoverflow.com/questions/4129430/qt-automated-testing > Please don't put that burden on everyone. Or at least be open and > reveal the reasoning. No, simply don't put this burden on people. UIs are a standard for a reason. This will not deter automation at all, it will simply make the people doing the automation either use smarter automation tools instead of "click this many pixels in from the right and this many pixels up from the bottom" to "click the button labeled 'OK', 'Ok', 'ok', 'Enter', 'Log', etc" What this will do, and already has done based on some of the emails I've read here, is cause people to click the wrong button because it was literally there 45 seconds ago and miss logging a contact. Or they will look into the code, find the part that does this, and remove or disable it. I realize it may not be up for a vote, but I vote an extremely strong no on this one. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bugies in 2.1.0
Re: Bill Somerville 2019-04-29 > > https://doc.qt.io/archives/qq/qq19-buttons.html > > > > Christoph > > Hi Christoph, > > not disagreeing but there are reasons for this that I can't reveal. Let's > just say it is to deter LIDs. Sorry. If the idea is to make people think before logging, I'd say this feature will merely induce stress that makes them focus on the buttons, and even less on the actual log. If the idea is to defeat automated operation, there are lots of tools that can identify and click buttons in GUI applications. https://stackoverflow.com/questions/4129430/qt-automated-testing Please don't put that burden on everyone. Or at least be open and reveal the reasoning. 73, Christoph ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bugies in 2.1.0
I can read between the lines and I think it’s fantastic. > On Apr 29, 2019, at 5:58 PM, Jim Nuytens via wsjt-devel > wrote: > > There's always a more determined LID. ;-) > >> On 4/29/2019 17:29, Bill Somerville wrote: >> Christoph, >> >> not disagreeing but there are reasons for this that I can't reveal. Let's >> just say it is to deter LIDs. Sorry. >> >> 73 >> Bill >> G4WJS. >> > > > --- > 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bugies in 2.1.0
There's always a more determined LID. ;-) On 4/29/2019 17:29, Bill Somerville wrote: Christoph, not disagreeing but there are reasons for this that I can't reveal. Let's just say it is to deter LIDs. Sorry. 73 Bill G4WJS. --- 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
Re: [wsjt-devel] Bugies in 2.1.0
On 29/04/2019 22:31, WB5JJJ wrote: I agree. I've hit CANCEL a couple of times instead of OK. Habit, Habit, Habit. George Hi George, sorry about that, but TBH you should be paying attention when logging QSOs. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bugies in 2.1.0
I agree. I've hit CANCEL a couple of times instead of OK. Habit, Habit, Habit. George On Mon, Apr 29, 2019 at 4:29 PM Christoph Berg wrote: > Re: Bill Somerville 2019-04-29 < > ddfd6e65-ec40-be34-c364-f44e43ca9...@classdesign.com> > > > Manual log qso, has Ok and Cancel buttons at least 4 different > positions > > > within different qsos > > This is intentional. Is it causing you insurmountable problems? > > Very annoying. There are styleguides that suggest putting the OK and > cancel buttons in certain places when using a toolkit so each app > behaves the same. Please follow them. > > https://doc.qt.io/archives/qq/qq19-buttons.html > > Christoph > > > ___ > 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
Re: [wsjt-devel] Bugies in 2.1.0
On 29/04/2019 22:26, Christoph Berg wrote: Re: Bill Somerville 2019-04-29 Manual log qso, has Ok and Cancel buttons at least 4 different positions within different qsos This is intentional. Is it causing you insurmountable problems? Very annoying. There are styleguides that suggest putting the OK and cancel buttons in certain places when using a toolkit so each app behaves the same. Please follow them. https://doc.qt.io/archives/qq/qq19-buttons.html Christoph Hi Christoph, not disagreeing but there are reasons for this that I can't reveal. Let's just say it is to deter LIDs. Sorry. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bugies in 2.1.0
Re: Bill Somerville 2019-04-29 > > Manual log qso, has Ok and Cancel buttons at least 4 different positions > > within different qsos > This is intentional. Is it causing you insurmountable problems? Very annoying. There are styleguides that suggest putting the OK and cancel buttons in certain places when using a toolkit so each app behaves the same. Please follow them. https://doc.qt.io/archives/qq/qq19-buttons.html Christoph ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bugies in 2.1.0
Hi Jari, comments in line below. On 29/04/2019 21:24, Jari A wrote: Some quick bugies: Windows 7 pro 64bit, When wsjt-x 210 start, rx audio level goes to +30db = full volume This is noted in the release announcement. It only happens with the Windows 64-bit build and will be fixed when the Qt team release a version with the defect fixed. Until then you will have to reset your audio input device level each time you start WSJT-X, switch configurations, or change the audio devices. Alternatively you can use the 32-bit build of WSJT-X v2.1.0 RC5. Manual log qso, has Ok and Cancel buttons at least 4 different positions within different qsos This is intentional. Is it causing you insurmountable problems? Change color, causes mode to jump to FT8 This is noted here several times. When leaving settings in FT4 mode you must reselect FT4 mode. The defect is fixed for the next release. Occasional loop in signal reporting, even high signal levels Can you provide the relevant section of your ALL.TXT file please. - opening 201, windows on desktop are messed up, wrong places and wrong sizes and mode gone to JT9 What exactly do you mean by "opening 201"? A sequence of steps to reproduce please. Regards, :Jari / oh2fqv 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Bugies in 2.1.0
Some quick bugies: Windows 7 pro 64bit, When wsjt-x 210 start, rx audio level goes to +30db = full volume Manual log qso, has Ok and Cancel buttons at least 4 different positions within different qsos Change color, causes mode to jump to FT8 Occasional loop in signal reporting, even high signal levels - opening 201, windows on desktop are messed up, wrong places and wrong sizes and mode gone to JT9 Regards, :Jari / oh2fqv ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
