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.
------------------------------------------------------------------------------
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
