[wsjt-devel] Drop down band-selector list problem

[Bill Mullin]

I posted this in another forum but got no answer, so I thought I'd try here.

This problem is difficult to describe!  From the new WSJT-X 2.2.1 user's 
manual:


"On a trial basis, and in response to numerous suggestions from around
the world, we have added a second set of suggested dial frequencies
for FT8 on three HF bands and also on 6 meters. The new suggested dial
frequencies are 7.071, 10.133, 14.071, and 50.310 MHz.  These
frequencies will appear in your drop-down band-selector list after you
go to the "Settings | Frequencies" tab, right-click on the frequency
table, and select "Reset".  Alternatively, you can add the new FT8
frequencies manually."

I tried adding the new frequencies both using the menus and then 
manually.  In both cases the FT8 portion of the drop down band-selector 
list become somewhat truncated.  The list is still usable so this should 
be considered a cosmetic problem only.


Note that I'd include a picture of the scrambled menu if I thought the 
group accepted attachments.  Note also the the FT4 menu is not affected 
by additions to the FT8 menu.


73, Bill - AA4M
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.x decode performance on RigPi

[Bill Somerville]

On 09/06/2020 01:03, Tony wrote:


From my post to a RigPi forum:

“Has anyone else tried running the latest WSJT-X 2.2.0 on a RigPi (3B+)?

The upgrade was straight forward and everything worked, but I found 
right away on a crowded band that the new decode method that splits 
things up during the 15 second cycle results in many decodes happening 
very late into the next 15 second cycle (as late as 10 seconds, which 
makes Tx response virtually impossible for those received 
transmissions). Tried with "Fast" and "Normal" decode and found that 
made no difference.


Ended up reverting back to 2.1.0, which works fine (even on a busy 
band).  I suspect WSJT-X 2.2.0 may be saving its results when doing 
multiple decodes to disk, and the microSD is not a really fast storage 
device.  Just a guess ... could be something else.”


This problem was confirmed by two other RigPi users and on different 
radio types using the RigPi.


‘73

AE0AU – Tony


Hi Tony,

disk i/o is not the issue, probably just more CPU resource required. 
"Menu->Decode->Fast" should be making a significant difference. What is 
the receiver? I ask because SDRs with high latency do not get the full 
benefit of the earliest decoding attempts.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX/Ras-pi/gpio

[Bill Somerville]

On 09/06/2020 01:02, Mark Sheffield wrote:


Just to close out this topic and perhaps save a future ham some 
frustration, the solution for me turned out to be:


rigctld-wsjtx -m 2004 -r /dev/ttyUSB0 -s 9600 -P GPIO*N* -p 17

using the *negated* strobe.

Thanks for the help, Bill – you put me onto the path of righteousness.

Rgds – Mark/K4LFL


Hi Mark,

thanks for the update, glad you have it working. Did you have an 
inverting switching transistor between the GPIO pin and the rig PTT?


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X 2.2.x decode performance on RigPi

[Tony]

>From my post to a RigPi forum:

“Has anyone else tried running the latest WSJT-X 2.2.0 on a RigPi (3B+)?

The upgrade was straight forward and everything worked, but I found right away 
on a crowded band that the new decode method that splits things up during the 
15 second cycle results in many decodes happening very late into the next 15 
second cycle (as late as 10 seconds, which makes Tx response virtually 
impossible for those received transmissions).  Tried with "Fast" and "Normal" 
decode and found that made no difference.

Ended up reverting back to 2.1.0, which works fine (even on a busy band).  I 
suspect WSJT-X 2.2.0 may be saving its results when doing multiple decodes to 
disk, and the microSD is not a really fast storage device.  Just a guess ... 
could be something else.”

This problem was confirmed by two other RigPi users and on different radio 
types using the RigPi.

‘73

AE0AU – Tony



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX/Ras-pi/gpio

[Mark Sheffield]

Just to close out this topic and perhaps save a future ham some frustration, 
the solution for me turned out to be:

rigctld-wsjtx -m 2004 -r /dev/ttyUSB0 -s 9600 -P GPION -p 17

using the negated strobe.

Thanks for the help, Bill - you put me onto the path of righteousness.

Rgds - Mark/K4LFL

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[Al Pawlowski]

No. That box is unchecked in my setup.



Al Pawlowski, K6AVP
Los Osos, CA USA



> On Jun 8, 2020, at 16:31, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Do you have "Monitor returns to last used frequency" turned on?
> That will cause the rig to wake up as it has to get the frequency.
> Mike W9MDB

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[tom]

Hi

Just noticed my Icom IC-9700 does it as well - personally would like this to be 
an option - or a way to turn off the rig when exiting the application that 
started it up.

Tom

--
73

Tom
GM8MJV (IO85)





> On 8 Jun 2020, at 23:48, Bill Somerville  wrote:
> 
> Mike,
> 
> how would calling rig_set_powerstat before calling rig_close stop Hamlib 
> unilaterally turning on some rigs. Also since only a few rigs can be turned 
> on by CAT commands the whole premiss that there is some new assumption that 
> the rig is turned on before Hamlib can do a rig_open is bogus. What's wrong 
> with an error return from rig_open that the application can deal with, 
> including calling rig_set_powerstat if it wants to. Libraries that control 
> hardware should not do things that have not been asked for. At least make 
> this new and unnecessary behaviour optional and controllable by the client 
> that is using the Hamlib library, it's not your job to. Do things that are 
> asked for, making it possible to do such things when asked for by the client 
> is fine.
> 
> 73
> Bill
> G4WJS.
> 
> On 08/06/2020 23:35, Black Michael via wsjt-devel wrote:
>> The assumption now is that if you ask hamlib to open the rig than the rig 
>> must be running...so if it's not turned on a power up is attempted.
>> WSJT-X expects a running rig too.
>> 
>> I had numerous requests for this capability from people running remote 
>> operations.  They didn't seem to have any problems turning their rig off but 
>> they were using rigctl to do it.
>> 
>> The only time this is done is when the rig is opened.
>> 
>> So...if you turn off the rig while WSJT-X is running I guess WSJT-X is 
>> reopening the rig causing the powerup again.
>> 
>> You could put in a powerdown checkbox and just call set_powerstat before you 
>> call rig_close.  That should work.
>> 
>> 
>> Mike W9MDB 
>> 
>> 
>> 
>> 
>> 
>> On Monday, June 8, 2020, 04:44:16 PM CDT, Bill Somerville 
>>   wrote:
>> 
>> 
>> Mike,
>> 
>> I think you mean "set the frequency".
>> 
>> Any chance of not having Hamlib unilaterally messing with the rig power 
>> on/off. A config option or just don't do it and leave it to the application 
>> to decide if this is appropriate?
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> On 08/06/2020 22:31, Black Michael via wsjt-devel wrote:
>>> Do you have "Monitor returns to last used frequency" turned on?
>>> 
>>> That will cause the rig to wake up as it has to get the frequency.
>>> 
>>> Mike W9MDB
>>> 
>>> 
>>> 
>>> 
>>> On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski  
>>>  wrote:
>>> 
>>> 
>>> Personally, I do not need/want WSJTx to turn my radio on, or off, when 
>>> starting or closing. But, it is no big problem for me either way and might 
>>> be useful for some. I just thought it odd that WSJTx tries to turn the 
>>> radio on when when it closes and had not noticed it doing either previously.
>>> 
>>> 
>>> Al Pawlowski, K6AVP
>>> Los Osos, CA USA
> 
> ___
> 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] v2.1.2 Radio On/Off CAT Problem?

[Joe Taylor]

Hi Mike,

On 6/8/2020 6:48 PM, Bill Somerville G4WJS wrote:

... Libraries that control hardware should not do things that have 
not been asked for. At least make this new and unnecessary behaviour 
optional and controllable by the client that is using the Hamlib 
library, it's not your job to. Do things that are asked for, making it 
possible to do such things when asked for by the client is fine.


I have to agree with Bill on this one.

-- Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[Bill Somerville]

Mike,

how would calling rig_set_powerstat before calling rig_close stop Hamlib 
unilaterally turning on some rigs. Also since only a few rigs can be 
turned on by CAT commands the whole premiss that there is some new 
assumption that the rig is turned on before Hamlib can do a rig_open is 
bogus. What's wrong with an error return from rig_open that the 
application can deal with, including calling rig_set_powerstat if it 
wants to. Libraries that control hardware should not do things that have 
not been asked for. At least make this new and unnecessary behaviour 
optional and controllable by the client that is using the Hamlib 
library, it's not your job to. Do things that are asked for, making it 
possible to do such things when asked for by the client is fine.


73
Bill
G4WJS.

On 08/06/2020 23:35, Black Michael via wsjt-devel wrote:
The assumption now is that if you ask hamlib to open the rig than the 
rig must be running...so if it's not turned on a power up is attempted.

WSJT-X expects a running rig too.

I had numerous requests for this capability from people running remote 
operations.  They didn't seem to have any problems turning their rig 
off but they were using rigctl to do it.


The only time this is done is when the rig is opened.

So...if you turn off the rig while WSJT-X is running I guess WSJT-X is 
reopening the rig causing the powerup again.


You could put in a powerdown checkbox and just call set_powerstat 
before you call rig_close.  That should work.



Mike W9MDB





On Monday, June 8, 2020, 04:44:16 PM CDT, Bill Somerville 
 wrote:



Mike,

I think you mean "set the frequency".

Any chance of not having Hamlib unilaterally messing with the rig 
power on/off. A config option or just don't do it and leave it to the 
application to decide if this is appropriate?


73
Bill
G4WJS.

On 08/06/2020 22:31, Black Michael via wsjt-devel wrote:

Do you have "Monitor returns to last used frequency" turned on?

That will cause the rig to wake up as it has to get the frequency.

Mike W9MDB




On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski 
  wrote:



Personally, I do not need/want WSJTx to turn my radio on, or off, 
when starting or closing. But, it is no big problem for me either way 
and might be useful for some. I just thought it odd that WSJTx tries 
to turn the radio on when when it closes and had not noticed it doing 
either previously.



Al Pawlowski, K6AVP
Los Osos, CA USA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[David Garnier]

Mike,
Remember my bug complaint about the 7300 doing this?  Well I looking at 
Settings, General screen anthe monitor off at start up is unchecked.  So I 
thinkthis is a bug.
BTW this turn off behavior is only present is v2.2.0release and not in v2.1.2
73’s Dave - Wb9own


Sent from a wireless can.


On Monday, June 8, 2020, 4:33 PM, Black Michael via wsjt-devel 
 wrote:

Do you have "Monitor returns to last used frequency" turned on?
That will cause the rig to wake up as it has to get the frequency.
Mike W9MDB

 

On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski  
wrote:  
 
 Personally, I do not need/want WSJTx to turn my radio on, or off, when 
starting or closing. But, it is no big problem for me either way and might be 
useful for some. I just thought it odd that WSJTx tries to turn the radio on 
when when it closes and had not noticed it doing either previously.

Al Pawlowski, K6AVP
Los Osos, CA USA




Date: Mon, 8 Jun 2020 08:49:50 -0700From: Al Pawlowski 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

___
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



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[Black Michael via wsjt-devel]

The assumption now is that if you ask hamlib to open the rig than the rig must 
be running...so if it's not turned on a power up is attempted.WSJT-X expects a 
running rig too.
I had numerous requests for this capability from people running remote 
operations.  They didn't seem to have any problems turning their rig off but 
they were using rigctl to do it.
The only time this is done is when the rig is opened.
So...if you turn off the rig while WSJT-X is running I guess WSJT-X is 
reopening the rig causing the powerup again.
You could put in a powerdown checkbox and just call set_powerstat before you 
call rig_close.  That should work.

Mike W9MDB 


 

On Monday, June 8, 2020, 04:44:16 PM CDT, Bill Somerville 
 wrote:  
 
  Mike, 
  I think you mean "set the frequency". 
  Any chance of not having Hamlib unilaterally messing with the rig power 
on/off. A config option or just don't do it and leave it to the application to 
decide if this is appropriate?
  
  73
 Bill
 G4WJS. 
  On 08/06/2020 22:31, Black Michael via wsjt-devel wrote:
  
   Do you have "Monitor returns to last used frequency" turned on? 
  That will cause the rig to wake up as it has to get the frequency. 
  Mike W9MDB 
   

  
  On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski  
wrote:  
  
Personally, I do not need/want WSJTx to turn my radio on, or off, when 
starting or closing. But, it is no big problem for me either way and might be 
useful for some. I just thought it odd that WSJTx tries to turn the radio on 
when when it closes and had not noticed it doing either previously. 
  
  Al Pawlowski, K6AVP
 Los Osos, CA USA   
 

 
 ___
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] v2.1.2 Radio On/Off CAT Problem?

[David Garnier]

Opps, make that turn on behavior only in v2.2.0WSJTx


Sent from a wireless can.


On Monday, June 8, 2020, 5:12 PM, David Garnier  wrote:

Mike,
Remember my bug complaint about the 7300 doing this?  Well I looking at 
Settings, General screen anthe monitor off at start up is unchecked.  So I 
thinkthis is a bug.
BTW this turn off behavior is only present is v2.2.0release and not in v2.1.2
73’s Dave - Wb9own


Sent from a wireless can.


On Monday, June 8, 2020, 4:33 PM, Black Michael via wsjt-devel 
 wrote:

Do you have "Monitor returns to last used frequency" turned on?
That will cause the rig to wake up as it has to get the frequency.
Mike W9MDB

 

On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski  
wrote:  
 
 Personally, I do not need/want WSJTx to turn my radio on, or off, when 
starting or closing. But, it is no big problem for me either way and might be 
useful for some. I just thought it odd that WSJTx tries to turn the radio on 
when when it closes and had not noticed it doing either previously.

Al Pawlowski, K6AVP
Los Osos, CA USA




Date: Mon, 8 Jun 2020 08:49:50 -0700From: Al Pawlowski 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

___
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






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[Bill Somerville]

Mike,

I think you mean "set the frequency".

Any chance of not having Hamlib unilaterally messing with the rig power 
on/off. A config option or just don't do it and leave it to the 
application to decide if this is appropriate?


73
Bill
G4WJS.

On 08/06/2020 22:31, Black Michael via wsjt-devel wrote:

Do you have "Monitor returns to last used frequency" turned on?

That will cause the rig to wake up as it has to get the frequency.

Mike W9MDB




On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski 
 wrote:



Personally, I do not need/want WSJTx to turn my radio on, or off, when 
starting or closing. But, it is no big problem for me either way and 
might be useful for some. I just thought it odd that WSJTx tries to 
turn the radio on when when it closes and had not noticed it doing 
either previously.



Al Pawlowski, K6AVP
Los Osos, CA USA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[Black Michael via wsjt-devel]

Do you have "Monitor returns to last used frequency" turned on?
That will cause the rig to wake up as it has to get the frequency.
Mike W9MDB

 

On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski  
wrote:  
 
 Personally, I do not need/want WSJTx to turn my radio on, or off, when 
starting or closing. But, it is no big problem for me either way and might be 
useful for some. I just thought it odd that WSJTx tries to turn the radio on 
when when it closes and had not noticed it doing either previously.

Al Pawlowski, K6AVP
Los Osos, CA USA




Date: Mon, 8 Jun 2020 08:49:50 -0700From: Al Pawlowski 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

___
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] v2.1.2 Radio On/Off CAT Problem?

[Al Pawlowski]

Personally, I do not need/want WSJTx to turn my radio on, or off, when starting 
or closing. But, it is no big problem for me either way and might be useful for 
some. I just thought it odd that WSJTx tries to turn the radio on when when it 
closes and had not noticed it doing either previously.


Al Pawlowski, K6AVP
Los Osos, CA USA



> Date: Mon, 8 Jun 2020 08:49:50 -0700
> From: Al Pawlowski mailto:k6...@almont.com>>
> To: wsjt-devel@lists.sourceforge.net 
> Subject: Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Marco Calistri]

Il 08/06/20 11:44, Bill Somerville ha scritto:
> On 08/06/2020 14:28, Marco Calistri wrote:
>> Il 08/06/20 10:21, Marco Calistri ha scritto:
>>
 Il 08/06/20 09:49, Bill Somerville ha scritto:
> Hi Marco,
>
> WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably
> support Qt 5.15 for the next release. My patch should be ok to get your
> build running, it just removes the compiler switch to convert warnings
> to errors. Please let us know how it goes?
>
> 73
> Bill
> G4WJS.
>> (SNIPPING PREVIOUS LINES!!)
>>
>> Bill, your patch did the job!
>>
>> I've been able to finish the source compiling and I'm going to test
>> WSJT-X 2.2.1 now :-)
>>
>> You rock!
>> -- 73 de Marco, PY1ZRJ (former IK5BCU)
> 
> Well done Marco!
> 
> Now work the DX ;)
> 
> 73
> Bill
> G4WJS.

That's a lot more hard due my very modest antenna (HVT-400B on balcony!).

I'm trying to setup a WSJTX on my Virtual Machine running Windows 7 32
bits, so far so good but I have some doubts how to start rigctld-wsjtx
in some way at WSJT-X startup and also I would like to get suggestions
regarding a good LOG software in order to manage WSJT-X from it.

On my Linux box I use CQRLOG but this software is unavailable on
Windows, I'm downloading LOGGER32 but may be there is something better
and lighter nowadays.

Thanks again Bill!


-- 

73 de Marco, PY1ZRJ (former IK5BCU)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[Alan Groups]

Well there's one other user here who may find that very useful when 
controlling the station from somewhere else other than my shack/study 
having been stuck in there in front of a PC screen for days on end while 
remote paid working!


I tend to agree it's not something for the mainstream though, except 
perhaps as a switchable option in WSJT-X?


Thanks for all your work in developing and maintaining hamlib.

Alan G0TLK

On 08/06/2020 17:33, Black Michael via wsjt-devel wrote:
I'm the hamlib primary developer right now and not inclined to turn 
off the rig when closing the client.  Not many people want that feature.


If you want to turn it off it's not hard to do.

Create a batch file and put this in it -- adjust paths and such to 
suit -- then create a shortcut to the batch file on your desktop you 
can use.


cd \WSJT\WSJTX
rigctl-wsjtx.exe -m 2014 -r com16 -s 115200 set_powerstat 0

Mike W9MDB



On Monday, June 8, 2020, 10:53:32 AM CDT, Al Pawlowski 
 wrote:



Forgot to say radio does not turn off, if on, when WSJTx is closed.


Al Pawlowski, K6AVP
Los Osos, CA USA



Date: Mon, 8 Jun 2020 08:45:15 -0700
From: Al Pawlowski mailto:k6...@almont.com>>
To:wsjt-devel@lists.sourceforge.net 


Subject: Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

Maybe it is a feature I had not noticed before. But, with  v2.2.1, my 
radio (OpenHPSDR using Kenwood TS2000 CAT emulation) is turned on 
when closing WSJTx and the radio is off.


This also happens when WSJTx is turned on, which seems good for 
remote control, but not so much for WSJT closing.


___
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set the own Rx frequency

[roland.hartmann]

Attached one example what maybe also for other is happened.

 

During FT8-Calls I got a direct call from EA3HKY   (not called from me before, 
also had not send a CQ before).

Friendly how I am I answer via double click.

SEND-Frequency is not changed.  I have to change it separately – than the 
sequence is going on.

 

Not a big issue – in the meantime I set the sending-frequency also.

But think such is not happened only for my ?!

 

(PS: Has nothing to do with “Hold TX Freq”. In addition those isn’t activated 
from my part.)

 

 



 

-Ursprüngliche Nachricht-
Von: Gary McDuffie  
Gesendet: Montag, 1. Juni 2020 07:51
An: WSJT software development 
Betreff: Re: [wsjt-devel] FT8: Double Click on entry in Rx Frequency only set 
the own Rx frequency

 

 

 

> On May 30, 2020, at 07:53,   
> roland.hartm...@web.de wrote:

> 

> In all other cases where I was not named as receiver Rx and Tx frequency are 
> changed.

 

You should check the HOLD TX box so the transmitter does NOT shift.  You should 
not call on the other station’s frequency.  Pick a clear frequency on your time 
cycle and call.

 

Gary - AG0N

 

___

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] v2.1.2 Radio On/Off CAT Problem?

[Black Michael via wsjt-devel]

I'm the hamlib primary developer right now and not inclined to turn off the rig 
when closing the client.  Not many people want that feature.
If you want to turn it off it's not hard to do.
Create a batch file and put this in it -- adjust paths and such to suit -- then 
create a shortcut to the batch file on your desktop you can use.
cd \WSJT\WSJTX rigctl-wsjtx.exe -m 2014 -r com16 -s 115200 set_powerstat 0

Mike W9MDB
 

On Monday, June 8, 2020, 10:53:32 AM CDT, Al Pawlowski  
wrote:  
 
 Forgot to say radio does not turn off, if on, when WSJTx is closed.

Al Pawlowski, K6AVP
Los Osos, CA USA



Date: Mon, 8 Jun 2020 08:45:15 -0700From: Al Pawlowski 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

Maybe it is a feature I had not noticed before. But, with  v2.2.1, my radio 
(OpenHPSDR using Kenwood TS2000 CAT emulation) is turned on when closing WSJTx 
and the radio is off.

This also happens when WSJTx is turned on, which seems good for remote control, 
but not so much for WSJT closing.

___
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] v2.1.2 Radio On/Off CAT Problem?

[Al Pawlowski]

Forgot to say radio does not turn off, if on, when WSJTx is closed.


Al Pawlowski, K6AVP
Los Osos, CA USA


> Date: Mon, 8 Jun 2020 08:45:15 -0700
> From: Al Pawlowski mailto:k6...@almont.com>>
> To: wsjt-devel@lists.sourceforge.net 
> Subject: Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?
> 
> Maybe it is a feature I had not noticed before. But, with  v2.2.1, my radio 
> (OpenHPSDR using Kenwood TS2000 CAT emulation) is turned on when closing 
> WSJTx and the radio is off.
> 
> This also happens when WSJTx is turned on, which seems good for remote 
> control, but not so much for WSJT closing.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[Al Pawlowski]

Maybe it is a feature I had not noticed before. But, with  v2.2.1, my radio 
(OpenHPSDR using Kenwood TS2000 CAT emulation) is turned on when closing WSJTx 
and the radio is off.

This also happens when WSJTx is turned on, which seems good for remote control, 
but not so much for WSJT closing.


Al Pawlowski, K6AVP
Los Osos, CA USA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Es fyi

[n2lo]

Sporatic E 

DE N2LO~>___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Bill Somerville]

On 08/06/2020 14:28, Marco Calistri wrote:

Il 08/06/20 10:21, Marco Calistri ha scritto:


Il 08/06/20 09:49, Bill Somerville ha scritto:

Hi Marco,

WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably
support Qt 5.15 for the next release. My patch should be ok to get your
build running, it just removes the compiler switch to convert warnings
to errors. Please let us know how it goes?

73
Bill
G4WJS.

(SNIPPING PREVIOUS LINES!!)

Bill, your patch did the job!

I've been able to finish the source compiling and I'm going to test
WSJT-X 2.2.1 now:-)

You rock!
-- 73 de Marco, PY1ZRJ (former IK5BCU)


Well done Marco!

Now work the DX ;)

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Wide Graph during TX

[Christoph Berg]

Re: Bill Somerville
> On 07/06/2020 20:48, Andy Durbin wrote:
> > So back to my original question - Why does WSJT-X freeze Wide Graph
> > during TX?
> 
> I suspect the answer is because for the vast majority of users it would be a
> hindrance, because Rx periods would scroll off screen twice as fast. This is
> particularly true for real weak signal working where a single trace that is
> barely visible is sought to set the Rx cursor on to.

Could we optionally have full-duplex capability? That would be awesome
for satellite (QO-100) operation.

Christoph


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Marco Calistri]

Il 08/06/20 10:21, Marco Calistri ha scritto:

>> Il 08/06/20 09:49, Bill Somerville ha scritto:

>>> Hi Marco,
>>>
>>> WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably
>>> support Qt 5.15 for the next release. My patch should be ok to get your
>>> build running, it just removes the compiler switch to convert warnings
>>> to errors. Please let us know how it goes?
>>>
>>> 73
>>> Bill
>>> G4WJS.
>>
(SNIPPING PREVIOUS LINES!!)

Bill, your patch did the job!

I've been able to finish the source compiling and I'm going to test
WSJT-X 2.2.1 now :-)

You rock!
-- 

73 de Marco, PY1ZRJ (former IK5BCU)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Marco Calistri]

Il 08/06/20 10:03, Marco Calistri ha scritto:
> Il 08/06/20 09:49, Bill Somerville ha scritto:
>> On 08/06/2020 13:45, Marco Calistri wrote:
>>> Il 08/06/20 09:06, Bill Somerville ha scritto:
 On 08/06/2020 04:22, Marco Calistri wrote:
> Hello,
>
> I noticed late tonight that a new WSJT-X release was available, then I
> downloaded and compiled 2.2.1.tgz in the same way I've done so far, but
> now I faced the following error related to a Qt5 deprecated statement:
>
> Scanning dependencies of target wsjtx_udp-static
> [  0%] Building CXX object
> CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
> In constructor ‘MessageServer::impl::impl(MessageServer*, const
> QString&, const QString&)’:
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
> error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
> deprecated: Use
> QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
> [-Werror=deprecated-declarations]
>42 | connect (this, static_cast
> (::error)
>   |
>  ^
> In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
>  from /usr/include/qt5/QtNetwork/QHostAddress:1,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
> /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
>   211 | void error(QAbstractSocket::SocketError);
>   |  ^
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
> error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
> deprecated: Use
> QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
> [-Werror=deprecated-declarations]
>42 | connect (this, static_cast
> (::error)
>   |
>  ^
> In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
>  from /usr/include/qt5/QtNetwork/QHostAddress:1,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
> /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
>   211 | void error(QAbstractSocket::SocketError);
>   |  ^
> cc1plus: all warnings being treated as errors
>
> If someone could suggest me a workaround, I would be very thankful.
>
> -- 73 de Marco, PY1ZRJ (former IK5BCU)
 Hi Marco,

 what Qt version does you your distribution have?

 The following patch will get you going for now.

 73
 Bill
 G4WJS.

 diff --git a/CMakeLists.txt b/CMakeLists.txt
 index a54983a5b..bd80913e4 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -921,7 +921,7 @@ set (CMAKE_VISIBILITY_INLINES_HIDDEN ON)
  #
  set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -Wextra")

 -set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror -Wall -Wextra 
 -fexceptions -frtti")
 +set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -fexceptions 
 -frtti")

  if (NOT APPLE)
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-pragmas")
>>> GM dear Bill!
>>>
>>> As I wrote before to Steve, I'm using latest Qt development
>>> version:5.15.0-1.2
>>>
>>> Repository: Repo-Oss
>>> Nome  : libQt5Network-devel
>>> Versione  : 5.15.0-1.2
>>> Arch. : x86_64
>>> Fornitore : openSUSE
>>> Dimensione installata : 442,8 KiB
>>> installato: Sì
>>> Stato : aggiornato
>>>
>>> May be is too recent?
>>>
>>> Thanks for the appended patch, I will try it.
>>>
>>> Regards,
>>> -- 73 de Marco, PY1ZRJ (former IK5BCU)
>>
>> Hi Marco,
>>
>> WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably
>> support Qt 5.15 for the next release. My patch should be ok to get your
>> build running, it just removes the compiler switch to convert warnings
>> to errors. Please let us know how it goes?
>>
>> 73
>> Bill
>> G4WJS.
> 
> Hi Bill,
> 
> I get a new error applying the wsjtx.patch:
> 
> [ 71%] Performing patch step for 'wsjtx'
> patching file CMakeLists.txt
> Hunk #1 FAILED at 921.
> 1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej
> gmake[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:103:
> wsjtx-prefix/src/wsjtx-stamp/wsjtx-patch] Errore 1
> gmake[2]: 

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Bill Somerville]

On 08/06/2020 14:03, Marco Calistri wrote:

Hi Marco,

WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably
support Qt 5.15 for the next release. My patch should be ok to get your
build running, it just removes the compiler switch to convert warnings
to errors. Please let us know how it goes?

73
Bill
G4WJS.

Hi Bill,

I get a new error applying the wsjtx.patch:

[ 71%] Performing patch step for 'wsjtx'
patching file CMakeLists.txt
Hunk #1 FAILED at 921.
1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej
gmake[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:103:
wsjtx-prefix/src/wsjtx-stamp/wsjtx-patch] Errore 1
gmake[2]: *** [CMakeFiles/Makefile2:165:
CMakeFiles/wsjtx-install.dir/all] Errore 2
gmake[1]: *** [CMakeFiles/Makefile2:253: CMakeFiles/install.dir/rule]
Errore 2
gmake: *** [Makefile:203: install] Errore 2

It contains:

cat wsjtx.patch

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -921,7 +921,7 @@ set (CMAKE_VISIBILITY_INLINES_HIDDEN ON)
  #
  set (CMAKE_C_FLAGS  -Wall -Wextra)

-set (CMAKE_CXX_FLAGS  -Werror -Wall -Wextra -fexceptions -frtti)
+set (CMAKE_CXX_FLAGS  -Wall -Wextra -fexceptions -frtti)

  if (NOT APPLE)
set (CMAKE_CXX_FLAGS  -Wno-pragmas)
-- 73 de Marco, PY1ZRJ (former IK5BCU)


Hi Marco,

where did you put the patch file?

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-2.2.x cmake error?

[Bill Somerville]

On 08/06/2020 14:00, nick wrote:

Linux Mint 19.3 x86_64, Qt 5.13.0.

When building wsjtx-2.1.2 cmake says...

-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- Configuring done
-- Generating done

But when building wsjtx-2.2.x cmake says...

-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Failed
-- Configuring done
-- Generating done

cmake --build . and cmake --build . --target install proceed without 
errors and the binaries appear to work.


Hi Nick,

that's fine, we have changed some compiler options that cause the CMake 
compiler feature tests to give different results, nothing to worry about.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Marco Calistri]

Il 08/06/20 09:49, Bill Somerville ha scritto:
> On 08/06/2020 13:45, Marco Calistri wrote:
>> Il 08/06/20 09:06, Bill Somerville ha scritto:
>>> On 08/06/2020 04:22, Marco Calistri wrote:
 Hello,

 I noticed late tonight that a new WSJT-X release was available, then I
 downloaded and compiled 2.2.1.tgz in the same way I've done so far, but
 now I faced the following error related to a Qt5 deprecated statement:

 Scanning dependencies of target wsjtx_udp-static
 [  0%] Building CXX object
 CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
 In constructor ‘MessageServer::impl::impl(MessageServer*, const
 QString&, const QString&)’:
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
 error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
 deprecated: Use
 QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
 [-Werror=deprecated-declarations]
42 | connect (this, static_cast
 (::error)
   |
  ^
 In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
 /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
 error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
 deprecated: Use
 QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
 [-Werror=deprecated-declarations]
42 | connect (this, static_cast
 (::error)
   |
  ^
 In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
 /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
 cc1plus: all warnings being treated as errors

 If someone could suggest me a workaround, I would be very thankful.

 -- 73 de Marco, PY1ZRJ (former IK5BCU)
>>> Hi Marco,
>>>
>>> what Qt version does you your distribution have?
>>>
>>> The following patch will get you going for now.
>>>
>>> 73
>>> Bill
>>> G4WJS.
>>>
>>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> index a54983a5b..bd80913e4 100644
>>> --- a/CMakeLists.txt
>>> +++ b/CMakeLists.txt
>>> @@ -921,7 +921,7 @@ set (CMAKE_VISIBILITY_INLINES_HIDDEN ON)
>>>  #
>>>  set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -Wextra")
>>>
>>> -set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror -Wall -Wextra 
>>> -fexceptions -frtti")
>>> +set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -fexceptions 
>>> -frtti")
>>>
>>>  if (NOT APPLE)
>>>set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-pragmas")
>> GM dear Bill!
>>
>> As I wrote before to Steve, I'm using latest Qt development
>> version:5.15.0-1.2
>>
>> Repository: Repo-Oss
>> Nome  : libQt5Network-devel
>> Versione  : 5.15.0-1.2
>> Arch. : x86_64
>> Fornitore : openSUSE
>> Dimensione installata : 442,8 KiB
>> installato: Sì
>> Stato : aggiornato
>>
>> May be is too recent?
>>
>> Thanks for the appended patch, I will try it.
>>
>> Regards,
>> -- 73 de Marco, PY1ZRJ (former IK5BCU)
> 
> Hi Marco,
> 
> WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably
> support Qt 5.15 for the next release. My patch should be ok to get your
> build running, it just removes the compiler switch to convert warnings
> to errors. Please let us know how it goes?
> 
> 73
> Bill
> G4WJS.

Hi Bill,

I get a new error applying the wsjtx.patch:

[ 71%] Performing patch step for 'wsjtx'
patching file CMakeLists.txt
Hunk #1 FAILED at 921.
1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej
gmake[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:103:
wsjtx-prefix/src/wsjtx-stamp/wsjtx-patch] Errore 1
gmake[2]: *** [CMakeFiles/Makefile2:165:
CMakeFiles/wsjtx-install.dir/all] Errore 2
gmake[1]: *** [CMakeFiles/Makefile2:253: CMakeFiles/install.dir/rule]
Errore 2
gmake: *** [Makefile:203: 

[wsjt-devel] wsjtx-2.2.x cmake error?

[nick]

Linux Mint 19.3 x86_64, Qt 5.13.0.

When building wsjtx-2.1.2 cmake says...

-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- Configuring done
-- Generating done

But when building wsjtx-2.2.x cmake says...

-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Failed
-- Configuring done
-- Generating done

cmake --build . and cmake --build . --target install proceed without 
errors and the binaries appear to work.




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Marco Calistri]

Il 08/06/20 09:49, Bill Somerville ha scritto:
> On 08/06/2020 13:45, Marco Calistri wrote:
>> Il 08/06/20 09:06, Bill Somerville ha scritto:
>>> On 08/06/2020 04:22, Marco Calistri wrote:
 Hello,

 I noticed late tonight that a new WSJT-X release was available, then I
 downloaded and compiled 2.2.1.tgz in the same way I've done so far, but
 now I faced the following error related to a Qt5 deprecated statement:

 Scanning dependencies of target wsjtx_udp-static
 [  0%] Building CXX object
 CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
 In constructor ‘MessageServer::impl::impl(MessageServer*, const
 QString&, const QString&)’:
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
 error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
 deprecated: Use
 QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
 [-Werror=deprecated-declarations]
42 | connect (this, static_cast
 (::error)
   |
  ^
 In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
 /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
 error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
 deprecated: Use
 QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
 [-Werror=deprecated-declarations]
42 | connect (this, static_cast
 (::error)
   |
  ^
 In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
 /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
 /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
 cc1plus: all warnings being treated as errors

 If someone could suggest me a workaround, I would be very thankful.

 -- 73 de Marco, PY1ZRJ (former IK5BCU)
>>> Hi Marco,
>>>
>>> what Qt version does you your distribution have?
>>>
>>> The following patch will get you going for now.
>>>
>>> 73
>>> Bill
>>> G4WJS.
>>>
>>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> index a54983a5b..bd80913e4 100644
>>> --- a/CMakeLists.txt
>>> +++ b/CMakeLists.txt
>>> @@ -921,7 +921,7 @@ set (CMAKE_VISIBILITY_INLINES_HIDDEN ON)
>>>  #
>>>  set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -Wextra")
>>>
>>> -set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror -Wall -Wextra 
>>> -fexceptions -frtti")
>>> +set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -fexceptions 
>>> -frtti")
>>>
>>>  if (NOT APPLE)
>>>set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-pragmas")
>> GM dear Bill!
>>
>> As I wrote before to Steve, I'm using latest Qt development
>> version:5.15.0-1.2
>>
>> Repository: Repo-Oss
>> Nome  : libQt5Network-devel
>> Versione  : 5.15.0-1.2
>> Arch. : x86_64
>> Fornitore : openSUSE
>> Dimensione installata : 442,8 KiB
>> installato: Sì
>> Stato : aggiornato
>>
>> May be is too recent?
>>
>> Thanks for the appended patch, I will try it.
>>
>> Regards,
>> -- 73 de Marco, PY1ZRJ (former IK5BCU)
> 
> Hi Marco,
> 
> WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably
> support Qt 5.15 for the next release. My patch should be ok to get your
> build running, it just removes the compiler switch to convert warnings
> to errors. Please let us know how it goes?
> 
> 73
> Bill
> G4WJS.

Very good Bill,

I'm just trying again, let you know ASAP.

Regards,
-- 

73 de Marco, PY1ZRJ (former IK5BCU)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Bill Somerville]

On 08/06/2020 13:45, Marco Calistri wrote:

Il 08/06/20 09:06, Bill Somerville ha scritto:

On 08/06/2020 04:22, Marco Calistri wrote:

Hello,

I noticed late tonight that a new WSJT-X release was available, then I
downloaded and compiled 2.2.1.tgz in the same way I've done so far, but
now I faced the following error related to a Qt5 deprecated statement:

Scanning dependencies of target wsjtx_udp-static
[  0%] Building CXX object
CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
In constructor ‘MessageServer::impl::impl(MessageServer*, const
QString&, const QString&)’:
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
[-Werror=deprecated-declarations]
42 | connect (this, static_cast
(::error)
   |
  ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
[-Werror=deprecated-declarations]
42 | connect (this, static_cast
(::error)
   |
  ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
cc1plus: all warnings being treated as errors

If someone could suggest me a workaround, I would be very thankful.

-- 73 de Marco, PY1ZRJ (former IK5BCU)

Hi Marco,

what Qt version does you your distribution have?

The following patch will get you going for now.

73
Bill
G4WJS.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a54983a5b..bd80913e4 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -921,7 +921,7 @@ set (CMAKE_VISIBILITY_INLINES_HIDDEN ON)
  #
  set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -Wextra")

-set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror -Wall -Wextra -fexceptions 
-frtti")
+set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -fexceptions -frtti")

  if (NOT APPLE)
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-pragmas")

GM dear Bill!

As I wrote before to Steve, I'm using latest Qt development
version:5.15.0-1.2

Repository: Repo-Oss
Nome  : libQt5Network-devel
Versione  : 5.15.0-1.2
Arch. : x86_64
Fornitore : openSUSE
Dimensione installata : 442,8 KiB
installato: Sì
Stato : aggiornato

May be is too recent?

Thanks for the appended patch, I will try it.

Regards,
-- 73 de Marco, PY1ZRJ (former IK5BCU)


Hi Marco,

WSJT-X is not yet validated with Qt v5.15, nor Qt v6. We will probably 
support Qt 5.15 for the next release. My patch should be ok to get your 
build running, it just removes the compiler switch to convert warnings 
to errors. Please let us know how it goes?


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Marco Calistri]

Il 08/06/20 09:06, Bill Somerville ha scritto:
> On 08/06/2020 04:22, Marco Calistri wrote:
>> Hello,
>>
>> I noticed late tonight that a new WSJT-X release was available, then I
>> downloaded and compiled 2.2.1.tgz in the same way I've done so far, but
>> now I faced the following error related to a Qt5 deprecated statement:
>>
>> Scanning dependencies of target wsjtx_udp-static
>> [  0%] Building CXX object
>> CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
>> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
>> In constructor ‘MessageServer::impl::impl(MessageServer*, const
>> QString&, const QString&)’:
>> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
>> error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
>> deprecated: Use
>> QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
>> [-Werror=deprecated-declarations]
>>42 | connect (this, static_cast
>> (::error)
>>   |
>>  ^
>> In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
>>  from /usr/include/qt5/QtNetwork/QHostAddress:1,
>>  from
>> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
>>  from
>> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
>> /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
>>   211 | void error(QAbstractSocket::SocketError);
>>   |  ^
>> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
>> error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
>> deprecated: Use
>> QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
>> [-Werror=deprecated-declarations]
>>42 | connect (this, static_cast
>> (::error)
>>   |
>>  ^
>> In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
>>  from /usr/include/qt5/QtNetwork/QHostAddress:1,
>>  from
>> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
>>  from
>> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
>> /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
>>   211 | void error(QAbstractSocket::SocketError);
>>   |  ^
>> cc1plus: all warnings being treated as errors
>>
>> If someone could suggest me a workaround, I would be very thankful.
>>
>> -- 73 de Marco, PY1ZRJ (former IK5BCU)
> 
> Hi Marco,
> 
> what Qt version does you your distribution have?
> 
> The following patch will get you going for now.
> 
> 73
> Bill
> G4WJS.
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index a54983a5b..bd80913e4 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -921,7 +921,7 @@ set (CMAKE_VISIBILITY_INLINES_HIDDEN ON)
>  #
>  set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -Wextra")
> 
> -set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror -Wall -Wextra -fexceptions 
> -frtti")
> +set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -fexceptions -frtti")
> 
>  if (NOT APPLE)
>set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-pragmas")

GM dear Bill!

As I wrote before to Steve, I'm using latest Qt development
version:5.15.0-1.2

Repository: Repo-Oss
Nome  : libQt5Network-devel
Versione  : 5.15.0-1.2
Arch. : x86_64
Fornitore : openSUSE
Dimensione installata : 442,8 KiB
installato: Sì
Stato : aggiornato

May be is too recent?

Thanks for the appended patch, I will try it.

Regards,
-- 

73 de Marco, PY1ZRJ (former IK5BCU)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Marco Calistri]

Il 08/06/20 08:13, Stephen VK3SIR ha scritto:
> Marco,
> 
> What OS, Version and Qt version are you using? Is your OS fully updated? Are 
> all required dependencies required to build WSJT-X as described in the WSJT-X 
> INSTALL and README files deployed? Are you following the instructions to 
> compile WSJT-X as described in the WSJT-X INSTALL file?
> 
> I run a Ubuntu 20.04 LTE release here that delivers Qt 5.12.8 packages 
> natively; I also run the Windows JTSDK 3.1 with the "Experimental" patches 
> (v.0.36). Both are pulling Hamlib from the G4WJS repository. I cannot 
> replicate what you are observing.
> 
> Based on the fact that this has "abended" very early in the WSJT-X compile 
> process I would suggest that the first thing that you should check is the Qt 
> deployment ! We may be able to assist further once we know a little more 
> about your development environment :-)
> 
> 73,
> 
> Steve I
> VK3VM / VK3SIR
> 
> -Original Message-
> From: Marco Calistri  
> Sent: Monday, 8 June 2020 1:22 PM
> To: 'WSJT software development' 
> Subject: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file
> 
> Hello,
> 
> I noticed late tonight that a new WSJT-X release was available, then I 
> downloaded and compiled 2.2.1.tgz in the same way I've done so far, but now I 
> faced the following error related to a Qt5 deprecated statement:
> 
> Scanning dependencies of target wsjtx_udp-static [  0%] Building CXX object 
> CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
> In constructor ‘MessageServer::impl::impl(MessageServer*, const QString&, 
> const QString&)’:
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
> error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
> deprecated: Use
> QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead 
> [-Werror=deprecated-declarations]
>42 | connect (this, static_cast
> (::error)
>   |
>  ^
> In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
>  from /usr/include/qt5/QtNetwork/QHostAddress:1,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
> /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
>   211 | void error(QAbstractSocket::SocketError);
>   |  ^
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
> error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
> deprecated: Use
> QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead 
> [-Werror=deprecated-declarations]
>42 | connect (this, static_cast
> (::error)
>   |
>  ^
> In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
>  from /usr/include/qt5/QtNetwork/QHostAddress:1,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
>  from
> /home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
> /usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
>   211 | void error(QAbstractSocket::SocketError);
>   |  ^
> cc1plus: all warnings being treated as errors
> 
> If someone could suggest me a workaround, I would be very thankful.
> 

Hello Steve,

Many thanks for your kind reply, as I wrote I followed same compiling
procedure since several WSJT-X releases backward and always succeeded,
also the 2.2.0 went well by following my compiling steps, only the
latest 2.2.1 has raised that error.

I'm using this openSUSE Tumbleweed package (Tumbleweed is a "rolling
distro" updated very frequently) which was the cause of the error:

libQt5Network-devel

Repository: Repo-Oss
Nome  : libQt5Network-devel
Versione  : 5.15.0-1.2
Arch. : x86_64
Fornitore : openSUSE
Dimensione installata : 442,8 KiB
installato: Sì
Stato : aggiornato

Which looks newer than your on Ubuntu.
-- 

73 de Marco, PY1ZRJ (former IK5BCU)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Bill Somerville]

On 08/06/2020 04:22, Marco Calistri wrote:

Hello,

I noticed late tonight that a new WSJT-X release was available, then I
downloaded and compiled 2.2.1.tgz in the same way I've done so far, but
now I faced the following error related to a Qt5 deprecated statement:

Scanning dependencies of target wsjtx_udp-static
[  0%] Building CXX object
CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
In constructor ‘MessageServer::impl::impl(MessageServer*, const
QString&, const QString&)’:
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
[-Werror=deprecated-declarations]
42 | connect (this, static_cast
(::error)
   |
  ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead
[-Werror=deprecated-declarations]
42 | connect (this, static_cast
(::error)
   |
  ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
  from /usr/include/qt5/QtNetwork/QHostAddress:1,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
  from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
   211 | void error(QAbstractSocket::SocketError);
   |  ^
cc1plus: all warnings being treated as errors

If someone could suggest me a workaround, I would be very thankful.

-- 73 de Marco, PY1ZRJ (former IK5BCU)


Hi Marco,

what Qt version does you your distribution have?

The following patch will get you going for now.

73
Bill
G4WJS.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a54983a5b..bd80913e4 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -921,7 +921,7 @@ set (CMAKE_VISIBILITY_INLINES_HIDDEN ON)
 #
 set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -Wextra")

-set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror -Wall -Wextra -fexceptions 
-frtti")
+set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -fexceptions -frtti")

 if (NOT APPLE)
   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-pragmas")


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

[Stephen VK3SIR]

Marco,

What OS, Version and Qt version are you using? Is your OS fully updated? Are 
all required dependencies required to build WSJT-X as described in the WSJT-X 
INSTALL and README files deployed? Are you following the instructions to 
compile WSJT-X as described in the WSJT-X INSTALL file?

I run a Ubuntu 20.04 LTE release here that delivers Qt 5.12.8 packages 
natively; I also run the Windows JTSDK 3.1 with the "Experimental" patches 
(v.0.36). Both are pulling Hamlib from the G4WJS repository. I cannot replicate 
what you are observing.

Based on the fact that this has "abended" very early in the WSJT-X compile 
process I would suggest that the first thing that you should check is the Qt 
deployment ! We may be able to assist further once we know a little more about 
your development environment :-)

73,

Steve I
VK3VM / VK3SIR

-Original Message-
From: Marco Calistri  
Sent: Monday, 8 June 2020 1:22 PM
To: 'WSJT software development' 
Subject: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

Hello,

I noticed late tonight that a new WSJT-X release was available, then I 
downloaded and compiled 2.2.1.tgz in the same way I've done so far, but now I 
faced the following error related to a Qt5 deprecated statement:

Scanning dependencies of target wsjtx_udp-static [  0%] Building CXX object 
CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
In constructor ‘MessageServer::impl::impl(MessageServer*, const QString&, const 
QString&)’:
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead 
[-Werror=deprecated-declarations]
   42 | connect (this, static_cast
(::error)
  |
 ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
 from /usr/include/qt5/QtNetwork/QHostAddress:1,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
  211 | void error(QAbstractSocket::SocketError);
  |  ^
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead 
[-Werror=deprecated-declarations]
   42 | connect (this, static_cast
(::error)
  |
 ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
 from /usr/include/qt5/QtNetwork/QHostAddress:1,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
  211 | void error(QAbstractSocket::SocketError);
  |  ^
cc1plus: all warnings being treated as errors

If someone could suggest me a workaround, I would be very thankful.

-- 

73 de Marco, PY1ZRJ (former IK5BCU)


___
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] 2.2.0 Call First Failures

[Adrian]

Have you tested 2.2.1 Jim ?


Adrian Fewster


On 8/6/20 4:43 pm, Jim Brown wrote:
A few times since loading the general release, I've found that I 
wasn't automatically answering callers responding to my CQ after 
receiving RR73 from the previous QSO. Instead, I called CQ again. Call 
First and Auto Seq were checked.  (I was running a short JA opening, 
and it is their habit to call with a signal report rather than their 
grid).


73, Jim K9YC






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] 2.2.0 Call First Failures

[Jim Brown]

A few times since loading the general release, I've found that I wasn't 
automatically answering callers responding to my CQ after receiving RR73 
from the previous QSO. Instead, I called CQ again. Call First and Auto 
Seq were checked.  (I was running a short JA opening, and it is their 
habit to call with a signal report rather than their grid).


73, Jim K9YC




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel