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
