subject:"Re\: \[wsjt\-devel\] Callsign highlighting"

Re: [wsjt-devel] Callsign highlighting

2018-03-27 Thread Alex, VE3NEA

Hi Bill,

Your latest message aggregator works perfectly, both in the highlight-last and list-based modes. WSJTX now does all that I want,
in terms of callsign highlighting. I used the new message to highlight the countries not worked this year, and improved my DX
Marathon score significantly in just one evening. Thank you for your effort!

73 Alex VE3NEA

On 2018-03-27 18:26, Bill Somerville wrote:

On 27/03/2018 04:10, Alex, VE3NEA wrote:
When I was initially experimenting with callsign highlighting, I painted all instances of the call that appeared after the
last separator. I searched for "" backwards from the end of the text, then searched forward for the callsign, starting at
that point. This proved to be unnecessary in the Highlight Last mode, but when this mode is off, you may want to use this
method to ensure that highlighting does not propagate beyond the point of the band change. Of course, this will work only if
separators are enabled.

Hi Alex,

thanks again fro the feedback.

For the above I think that it is best left for the future when we have a much richer internal model of decodes, things like the
dial frequency when they were decoded will eventually be stored alongside the decoded text, date, time etc. This will make this
sort of logic far more practical. I suspect for the vast majority of users there is little care for decodes that have scrolled
off the top unless they are for the last one or two T/R periods.

I have added a bit more functionality to the message_aggregator reference application to exercise the highlight last instance
only flag and to allow the selection of foreground and background colours in the "Calls of interest" list. This is only so I can
test the message functionality fully, there are no WSJT-X implementation changes. Here's a new patch for any who might be
interested:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

I consider this patch a low risk and I am happy to merge it to the development branch even though we are already at RC3, which
means it will make it into the v1.9.0 GA release. Unless you have any other suggestions on this functionality I will commit the
changes tomorrow.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-27 Thread Bill Somerville


On 27/03/2018 04:10, Alex, VE3NEA wrote:
When I was initially experimenting with callsign highlighting, I 
painted all instances of the call that appeared after the last 
separator. I searched for "" backwards from the end of the text, 
then searched forward for the callsign, starting at that point. This 
proved to be unnecessary in the Highlight Last mode, but when this 
mode is off, you may want to use this method to ensure that 
highlighting does not propagate beyond the point of the band change. 
Of course, this will work only if separators are enabled.


Hi Alex,

thanks again fro the feedback.

For the above I think that it is best left for the future when we have a 
much richer internal model of decodes, things like the dial frequency 
when they were decoded will eventually be stored alongside the decoded 
text, date, time etc. This will make this sort of logic far more 
practical. I suspect for the vast majority of users there is little care 
for decodes that have scrolled off the top unless they are for the last 
one or two T/R periods.


I have added a bit more functionality to the message_aggregator 
reference application to exercise the highlight last instance only flag 
and to allow the selection of foreground and background colours in the 
"Calls of interest" list. This is only so I can test the message 
functionality fully, there are no WSJT-X implementation changes. Here's 
a new patch for any who might be interested:


https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

I consider this patch a low risk and I am happy to merge it to the 
development branch even though we are already at RC3, which means it 
will make it into the v1.9.0 GA release. Unless you have any other 
suggestions on this functionality I will commit the changes tomorrow.


73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-26 Thread Alex, VE3NEA

Thank you very much, Bill! You work very fast. I applied your patch, and the code worked perfectly. I am sure that there will be
developers who will take full advantage of the callsign color list, and those who will use the Highlight Last mode to have more
control.

The reason why I want to highlight only the senders' calls is because one can double-click on them and start calling right away,
while the stations whose calls are on the left side may not even be copyable, and double-clicking on them is not going to start
a QSO with them. The Highlight Last option allows the server to specify the color for the left hand or the right hand call, or
for both, and pass either the same or different colors. There is no need to add another option for that.

When I was initially experimenting with callsign highlighting, I painted all instances of the call that appeared after the last
separator. I searched for "" backwards from the end of the text, then searched forward for the callsign, starting at that
point. This proved to be unnecessary in the Highlight Last mode, but when this mode is off, you may want to use this method to
ensure that highlighting does not propagate beyond the point of the band change. Of course, this will work only if separators
are enabled.

73 Alex VE3NEA

On 2018-03-26 19:34, Bill Somerville wrote:

Hi Alex,

thanks for reviewing the changes. Some comments in line below.

On 26/03/2018 18:23, Alex, VE3NEA wrote:
1. Some developers may prefer to highlight only the senders' callsigns, or at least use different colors depending on the
callsign position in the message. Your code does not allow this.
I'm not sure this is of great value as the callsign orders swap each period. I expect highlighting to be used either to indicate
stations of higher value or worked before, either way it doesn't seem to matter which call position is being highlighted. I need
more convincing on adding a position1/position2 specific highlighting capability.

2. The server may not be running when a call whose status has changed is decoded again, this results in incorrect
highlighting. If there is no up to date info, it might be better not to highlight at all.
The server does have the option to clear all the highlighting it has requested, of course this does rely on the server making a
graceful exit. We must also be careful not to disrupt multiple servers, that might be highlighting different calls, although I
don't see any immediate advantage to doing that, for sure the WSJT-X protocol does not disallow it if multicast group addresses
are used.

3. When the status of a callsign changes, e.g. because we have worked it, the new colors are applied to all historical data,
which is incorrect since the call was not a dupe until it was worked.
I see your point although I'm not sure it matters much, working a station is an event in time but what's the harm in
highlighting all instances of that call as un-needed once it has been captured. Having said that switching bands has a bearing
here, maybe WSJT-X should forget all highlighting when switching bands, OTOH the server could do that itself too.

All these issues could be fixed by adding an option to the highlight message that tells the client to apply the colors only to
the last instance of the call and not to add an entry to the list.

That is certainly quite easy to implement and it does add an extra capability. It would certainly facilitate a more dynamic
approach which I think is your prime goal. The highlighting would still be cleared if a message with invalid colours were passed.

I am a little concerned that only highlighting one instance of a callsign might confuse users, imagine a busy band where message
scrolls away quickly, I assume you intend to have the server keep highlighting the callsign each time it is seen in a decode and
therefore keeping the information current.

Here is another patch:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

I haven't updated the message_aggregator application to exercise the "last_only" callsign highlight option as I am out of time
with an early start for work in the morning, but you have that option now.

If you want to reverse out the previous patch then add a -R option to the previous patch command, or simply revert the files in
svn. A reverse patch must be done with the original patch file so beware that I have used the same file name and overwritten the
Dropbox file.

73
Bill
G4WJS.

Re: [wsjt-devel] Callsign highlighting

2018-03-26 Thread Bill Somerville


Hi Alex,

thanks for reviewing the changes. Some comments in line below.

On 26/03/2018 18:23, Alex, VE3NEA wrote:
1. Some developers may prefer to highlight only the senders' 
callsigns, or at least use different colors depending on the callsign 
position in the message. Your code does not allow this.
I'm not sure this is of great value as the callsign orders swap each 
period. I expect highlighting to be used either to indicate stations of 
higher value or worked before, either way it doesn't seem to matter 
which call position is being highlighted. I need more convincing on 
adding a position1/position2 specific highlighting capability.


2. The server may not be running when a call whose status has changed 
is decoded again, this results in incorrect highlighting. If there is 
no up to date info, it might be better not to highlight at all.
The server does have the option to clear all the highlighting it has 
requested, of course this does rely on the server making a graceful 
exit. We must also be careful not to disrupt multiple servers, that 
might be highlighting different calls, although I don't see any 
immediate advantage to doing that, for sure the WSJT-X protocol does not 
disallow it if multicast group addresses are used.


3. When the status of a callsign changes, e.g. because we have worked 
it, the new colors are applied to all historical data, which is 
incorrect since the call was not a dupe until it was worked.
I see your point although I'm not sure it matters much, working a 
station is an event in time but what's the harm in highlighting all 
instances of that call as un-needed once it has been captured. Having 
said that switching bands has a bearing here, maybe WSJT-X should forget 
all highlighting when switching bands, OTOH the server could do that 
itself too.


All these issues could be fixed by adding an option to the highlight 
message that tells the client to apply the colors only to the last 
instance of the call and not to add an entry to the list.


That is certainly quite easy to implement and it does add an extra 
capability. It would certainly facilitate a more dynamic approach which 
I think is your prime goal. The highlighting would still be cleared if a 
message with invalid colours were passed.


I am a little concerned that only highlighting one instance of a 
callsign might confuse users, imagine a busy band where message scrolls 
away quickly, I assume you intend to have the server keep highlighting 
the callsign each time it is seen in a decode and therefore keeping the 
information current.


Here is another patch:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

I haven't updated the message_aggregator application to exercise the 
"last_only" callsign highlight option as I am out of time with an early 
start for work in the morning, but you have that option now.


If you want to reverse out the previous patch then add a -R option to 
the previous patch command, or simply revert the files in svn. A reverse 
patch must be done with the original patch file so beware that I have 
used the same file name and overwritten the Dropbox file.


73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-26 Thread Alex, VE3NEA


Hi Bill,

I applied your patch to WSJT-X and changed my UDP server to send two QColor parameters, everything works fine. However, there 
are a few issues due to storing the list of highlighted calls.


1. Some developers may prefer to highlight only the senders' callsigns, or at least use different colors depending on the 
callsign position in the message. Your code does not allow this.


2. The server may not be running when a call whose status has changed is decoded again, this results in incorrect highlighting. 
If there is no up to date info, it might be better not to highlight at all.


3. When the status of a callsign changes, e.g. because we have worked it, the new colors are applied to all historical data, 
which is incorrect since the call was not a dupe until it was worked.


All these issues could be fixed by adding an option to the highlight message that tells the client to apply the colors only to 
the last instance of the call and not to add an entry to the list.


73 Alex VE3NEA

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-26 Thread Bill Somerville


Hi Alex,

patch works fine for me:

bill@BILLS_LENOVO ~/src/wsjt ((a4e77bb...))

$ patch --dry-run -p1 <~/Dropbox/Public/highlight.diff
patching file `CMakeLists.txt'
patching file `MessageClient.cpp'
patching file `MessageClient.hpp'
patching file `MessageServer.cpp'
patching file `MessageServer.hpp'
patching file `NetworkMessage.hpp'
patching file `UDPExamples/ClientWidget.cpp'
patching file `UDPExamples/ClientWidget.hpp'
patching file `UDPExamples/MessageAggregatorMainWindow.cpp'
patching file `UDPExamples/MessageAggregatorMainWindow.hpp'
patching file `displaytext.cpp'
patching file `displaytext.h'
patching file `mainwindow.cpp'

bill@BILLS_LENOVO ~/src/wsjt ((a4e77bb...))
$ which patch
/bin/patch

Using the patch utility found in a Windows git-bash installation but any 
correctly installed GNU patch should work.


73
Bill
G4WJS.

On 26/03/2018 02:26, Alex, VE3NEA wrote:

Hi Bill,

The patch utility crashes when trying to apply this patch. Do I need 
to specify some extra command line switches? Maybe you could create a 
branch with your changes that I would check out instead?


73 Alex VE3NEA



On 2018-03-25 18:52, Bill Somerville wrote:

Hi Alex,

I have added a few enhancements to your proposed patch:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

this extends the UDP message to include the foreground colour as well 
as the background colour. The colours are passed as QColor format 
fields which are a little more complicated but are already supported 
by the Qt QDataStream formats. The main reason for the field format 
is that QColor can specify many more colours and also an  invalid 
colour value (spec = 0). The invalid value is used to reset the 
background and or foreground colour to defaults. The internal 
implementation in WSJT-X keeps a dictionary of highlight commands 
send and applies the colours to all existing decodes and future 
decodes, this should explain the need for a resetting mechanism.


As an example I have enhanced the WSJT-X MessageServer class and the 
reference message_aggregator application (the C++ Qt one) provided 
with WSJT-X to exercise the new UDP message, it does so by displaying 
a list of "calls of interest" which it relays to all connected WSJT-X 
clients. Callsigns may be added to, edited, and deleted (right-click 
the list for a context menu).


Give it a try and see what you think.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-25 Thread Alex, VE3NEA

Hi Bill,

The patch utility crashes when trying to apply this patch. Do I need to specify some extra command line switches? Maybe you
could create a branch with your changes that I would check out instead?

73 Alex VE3NEA

On 2018-03-25 18:52, Bill Somerville wrote:

Hi Alex,

I have added a few enhancements to your proposed patch:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

this extends the UDP message to include the foreground colour as well as the background colour. The colours are passed as QColor
format fields which are a little more complicated but are already supported by the Qt QDataStream formats. The main reason for
the field format is that QColor can specify many more colours and also an invalid colour value (spec = 0). The invalid value is
used to reset the background and or foreground colour to defaults. The internal implementation in WSJT-X keeps a dictionary of
highlight commands send and applies the colours to all existing decodes and future decodes, this should explain the need for a
resetting mechanism.

As an example I have enhanced the WSJT-X MessageServer class and the reference message_aggregator application (the C++ Qt one)
provided with WSJT-X to exercise the new UDP message, it does so by displaying a list of "calls of interest" which it relays to
all connected WSJT-X clients. Callsigns may be added to, edited, and deleted (right-click the list for a context menu).

Give it a try and see what you think.

73
Bill
G4WJS.

Re: [wsjt-devel] Callsign highlighting

2018-03-24 Thread Alex, VE3NEA


Hi Saku,

Your logger knows a lot about the callsigns it displays. Once my changes are merged, cqrlog will be able to share some of this 
knowledge with WSJT-X so that the operator can see your colors directly in the Band Activity panel. You can use my 
TWsjtxListener class if you want, I hope it will compile in Lazarus without problems. I have added schema negotiation as Bill 
suggested, please re-download.


73 Alex VE3NEA



On 2018-03-24 06:20, Saku wrote:

Alex, VE3NEA kirjoitti 23.03.2018 klo 22:41:

Hello,

I have written some code that allows a UDP server, e.g., a logger, to tell WSJT-X what background color to use for each 
callsign in the Band Activity panel. This might be useful to those who chase various awards, if the logger assigns different 
colors to new IOTA groups, US counties, etc. The end result looks like on the attached screenshot. The .diff file is here:


Hi !


Quite same what cqrlog does on it's own CQ-monitor.

Colors of calls and locators vary (with up/lowcase ltrs) telling status 
compared to own log ( in Mysql database).

It also warns (keep cool =blue) about directed CQ if own continent compared to 
caller continent is same (I'm no DX) or if directed
call is not directed to own continent.

Cq's can be answered by double click of corresponding line. "Follow" property's line can also be double clicked and it uses 
1.9.0.rc3 new

feature that loads Std messages, but does not fire TX.

--
Saku
OH1KH



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-24 Thread Steve Nance

I too have an auxiliary app to keep up with what FT8 stations are needed for 
new ones.

https://docs.google.com/document/d/1LoHQNZf4_RaPzUXQ3A_yxZYJqpEX4eCfxgyFNdqDtG8/edit#heading=h.6jynaot9cbnq

 

73, Steve K5FR

 

From: Saku [mailto:oh...@sral.fi] 
Sent: Saturday, March 24, 2018 05:20 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Callsign highlighting

 

Alex, VE3NEA kirjoitti 23.03.2018 klo 22:41:

Hello, 

I have written some code that allows a UDP server, e.g., a logger, to tell 
WSJT-X what background color to use for each callsign in the Band Activity 
panel. This might be useful to those who chase various awards, if the logger 
assigns different colors to new IOTA groups, US counties, etc. The end result 
looks like on the attached screenshot. The .diff file is here: 

Hi !

 

Quite same what cqrlog does on it's own CQ-monitor.

Colors of calls and locators vary (with up/lowcase ltrs) telling status 
compared to own log ( in Mysql database).

It also warns (keep cool =blue) about directed CQ if own continent compared to 
caller continent is same (I'm no DX) or if directed
call is not directed to own continent.

Cq's can be answered by double click of corresponding line. "Follow" property's 
line can also be double clicked and it uses 1.9.0.rc3 new
feature that loads Std messages, but does not fire TX.



-- 
Saku
OH1KH

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-24 Thread Saku


Alex, VE3NEA kirjoitti 23.03.2018 klo 22:41:

Hello,

I have written some code that allows a UDP server, e.g., a logger, to 
tell WSJT-X what background color to use for each callsign in the Band 
Activity panel. This might be useful to those who chase various 
awards, if the logger assigns different colors to new IOTA groups, US 
counties, etc. The end result looks like on the attached screenshot. 
The .diff file is here:


Hi !


Quite same what cqrlog does on it's own CQ-monitor.

Colors of calls and locators vary (with up/lowcase ltrs) telling status 
compared to own log ( in Mysql database).


It also warns (keep cool =blue) about directed CQ if own continent 
compared to caller continent is same (I'm no DX) or if directed

call is not directed to own continent.

Cq's can be answered by double click of corresponding line. "Follow" 
property's line can also be double clicked and it uses 1.9.0.rc3 new

feature that loads Std messages, but does not fire TX.

--
Saku
OH1KH

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-23 Thread Morris Wideman via wsjt-devel

 This would be a big help to have callsigns color coded, would it also be 
possible to code in filters where some messages are not shown such as other on 
going qso`s that are not necessary to view and even stations that have been 
worked B4. This would de-clutter busy screens that have so many decodes you 
cannot even view them all. I sometimes feel this is why some stations are a 
sequence or two late answering callsthey do not see them they have scrolled out 
of view. These could be an option only if the operator wanted to 
activate.Thanks for your consideration73 wa4mit Morris
On Friday, March 23, 2018, 4:35:57 PM CDT, Alex, VE3NEA 
 wrote:  
 
 Hi Bill,

Thank you for a link to your message aggregator. I will take a closer look at 
it tonight, it looks like it includes a useful 
piece of code for working with the wsjt-x messages.

I included the Delphi project only as a testing tool for the new feature in 
wsjt-x, so please ignore it if it is incomplete.

My C++ code does not change the caret position, the callsign is highlighted 
using a temporary cursor object.

73 Alex VE3NEA



On 2018-03-23 17:14, Bill Somerville wrote:
> On 23/03/2018 20:41, Alex, VE3NEA wrote:
>> I have written some code that allows a UDP server, e.g., a logger, to tell 
>> WSJT-X what background color to use for each 
>> callsign in the Band Activity panel. This might be useful to those who chase 
>> various awards, if the logger assigns different 
>> colors to new IOTA groups, US counties, etc. The end result looks like on 
>> the attached screenshot. The .diff file is here:
>>
>> http://www.dxatlas.com/Misc/callsign_highlight.zip
>>
>> The zip also includes a Delphi class for listening and replying to the 
>> WSJT-X messages, and a demo program that shows how to 
>> use the class, which is also useful for testing the new feature once it is 
>> included in WSJT-X.
>>
>> Please review and merge if OK.
> 
> Hi Alex,
> 
> looks good but I have some issues. Please check out this: 
> https://www.dropbox.com/s/xlvc5kxy85ymtn9/message_aggregator.zip?dl=0 
> , it is a very basic UDP message server application written in Object Pascal 
> and also uses Indy for services. The message 
> cracking routines may be useful to you, free free to copy them - all I 
> require is credit.
> 
> I will look in more detail at your patch, I have a concern about cursor 
> positioning in the decode windows that I need to check.
> 
> There is a requirement to negotiate the message schema number if you intend 
> to send messages back to WSJT-X instances, this is 
> necessary in case a new schema is introduced as the WSJT-X UDP messages are a 
> grid topology and all nodes must agree on the "on 
> the wire" message schema. The schema number is allowed to decrease if an old 
> lower schema node joins the party. The 
> MessageServer.cpp class in the WSJT-X sources does this correctly. See code 
> at line 155 handling Heartbeat messages here: 
> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.cpp
>  .
> 
> I also have a partial implementation of joining a multicast group for the 
> AutoIt scripting language, this is relevant because it 
> has no built in library support for multicast and it is used to implement the 
> current version of JTAlert, so JTAlert must bind a 
> unicast address for now. If JTAlert is in the grid then it must degrade to a 
> single server (JTAlert) many client (WSJT-X) 
> topology, which excludes other servers :( I need to find time to complete 
> this and offer it to Laurie as a plug in replacement 
> for the AutoIt UDP server module.
> 
> 73
> Bill
> G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

2018-03-23 Thread Alex, VE3NEA

Hi Bill,

Thank you for a link to your message aggregator. I will take a closer look at it tonight, it looks like it includes a useful
piece of code for working with the wsjt-x messages.

I included the Delphi project only as a testing tool for the new feature in
wsjt-x, so please ignore it if it is incomplete.

My C++ code does not change the caret position, the callsign is highlighted
using a temporary cursor object.

73 Alex VE3NEA

On 2018-03-23 17:14, Bill Somerville wrote:

On 23/03/2018 20:41, Alex, VE3NEA wrote:
I have written some code that allows a UDP server, e.g., a logger, to tell WSJT-X what background color to use for each
callsign in the Band Activity panel. This might be useful to those who chase various awards, if the logger assigns different
colors to new IOTA groups, US counties, etc. The end result looks like on the attached screenshot. The .diff file is here:

http://www.dxatlas.com/Misc/callsign_highlight.zip

The zip also includes a Delphi class for listening and replying to the WSJT-X messages, and a demo program that shows how to
use the class, which is also useful for testing the new feature once it is included in WSJT-X.

Please review and merge if OK.

Hi Alex,

looks good but I have some issues. Please check out this: https://www.dropbox.com/s/xlvc5kxy85ymtn9/message_aggregator.zip?dl=0
, it is a very basic UDP message server application written in Object Pascal and also uses Indy for services. The message
cracking routines may be useful to you, free free to copy them - all I require is credit.

I will look in more detail at your patch, I have a concern about cursor
positioning in the decode windows that I need to check.

There is a requirement to negotiate the message schema number if you intend to send messages back to WSJT-X instances, this is
necessary in case a new schema is introduced as the WSJT-X UDP messages are a grid topology and all nodes must agree on the "on
the wire" message schema. The schema number is allowed to decrease if an old lower schema node joins the party. The
MessageServer.cpp class in the WSJT-X sources does this correctly. See code at line 155 handling Heartbeat messages here:
https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.cpp .

I also have a partial implementation of joining a multicast group for the AutoIt scripting language, this is relevant because it
has no built in library support for multicast and it is used to implement the current version of JTAlert, so JTAlert must bind a
unicast address for now. If JTAlert is in the grid then it must degrade to a single server (JTAlert) many client (WSJT-X)
topology, which excludes other servers :( I need to find time to complete this and offer it to Laurie as a plug in replacement
for the AutoIt UDP server module.

73
Bill
G4WJS.

Re: [wsjt-devel] Callsign highlighting

2018-03-23 Thread Bill Somerville


On 23/03/2018 20:41, Alex, VE3NEA wrote:
I have written some code that allows a UDP server, e.g., a logger, to 
tell WSJT-X what background color to use for each callsign in the Band 
Activity panel. This might be useful to those who chase various 
awards, if the logger assigns different colors to new IOTA groups, US 
counties, etc. The end result looks like on the attached screenshot. 
The .diff file is here:


http://www.dxatlas.com/Misc/callsign_highlight.zip

The zip also includes a Delphi class for listening and replying to the 
WSJT-X messages, and a demo program that shows how to use the class, 
which is also useful for testing the new feature once it is included 
in WSJT-X.


Please review and merge if OK.


Hi Alex,

looks good but I have some issues. Please check out this: 
https://www.dropbox.com/s/xlvc5kxy85ymtn9/message_aggregator.zip?dl=0 , 
it is a very basic UDP message server application written in Object 
Pascal and also uses Indy for services. The message cracking routines 
may be useful to you, free free to copy them - all I require is credit.


I will look in more detail at your patch, I have a concern about cursor 
positioning in the decode windows that I need to check.


There is a requirement to negotiate the message schema number if you 
intend to send messages back to WSJT-X instances, this is necessary in 
case a new schema is introduced as the WSJT-X UDP messages are a grid 
topology and all nodes must agree on the "on the wire" message schema. 
The schema number is allowed to decrease if an old lower schema node 
joins the party. The MessageServer.cpp class in the WSJT-X sources does 
this correctly. See code at line 155 handling Heartbeat messages here: 
https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.cpp 
.


I also have a partial implementation of joining a multicast group for 
the AutoIt scripting language, this is relevant because it has no built 
in library support for multicast and it is used to implement the current 
version of JTAlert, so JTAlert must bind a unicast address for now. If 
JTAlert is in the grid then it must degrade to a single server (JTAlert) 
many client (WSJT-X) topology, which excludes other servers :( I need to 
find time to complete this and offer it to Laurie as a plug in 
replacement for the AutoIt UDP server module.


73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

Re: [wsjt-devel] Callsign highlighting

13 matches

Site Navigation

Mail list logo

Footer information