On 21/11/2015 16:05, Steven Franke wrote: > Hi Joe, Bill, and all, > > Is there any objection to me committing the attached patch to the wsjtx > development branch? It is a change to the on_bandComboBox_currentIndexChanged > routine. It causes the user_hardware script to be called whenever the band is > changed via the band combo-box. > > I believe that this change should have no impact on users who do not have a > user_hardware script in the execution directory. > > Steve k9an Hi Steve,
there are a number of issues with this, some already extant with the similar code in the WSPR band hopping function. The script should only be executed if the band is valid inside the !bandisEmpty() block just above, having a user put files in the install directory is not advisable as it will break the installer on Windows and requires root privs on Linux, running an executable from another executable is a security vulnerability, but we are deep in that bad place already :( there are couple of minor issues with the efficiency of the code fragment itself, the external executable will be called twice or there will be QProcess error when WSPR band hopping. It might be better to allow the user executable to be looked up via the PATH env variable i.e. provide no directory path, but that also has security implications, better still we could provide a user band change script path in the settings. Checking for file existence is more complicated if PATH is used but leaving it to the shell might be a better option i.e. catch QProcess::QProcessError == QProcess::FailedToStart (there is still an issue as that doesn't differentiate between missing and no permission). Having this code in WSPR band hopping is not necessary if it is added where you propose. That also brings up the issue of the timing of the tune up transmission in the WSPR band hopping function. Currently there is no guarantee that the rig has actually been QSYed when the tune up sequence starts. The reason for this is the, necessarily, asynchronous nature of the rig control functionality. There are places where we know the rig has changed frequency and perhaps that is where both running this executable and doing a tune up transmission should be done. A whole different approach might be to delegate this all to the rig control functionality where it can be done synchronously without blocking the UI. 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
