Well, I am not sure. FICS ivar mechanism is very elaborate. Funny enough ivars and the iset command seem to have a rudimentary implementation in the ICS code. But there are only 3 ivariables, (implemented as explicitly named fields in a struct, rather than defined in a list of name + handler like normal vars): lock, ms and startpos. The latter two can be set, but aren't used anywhere else in the code.Michel wrote:Isn't is a bit dangerous to implement yet another mechanism for this? Wouldn't it be better to implement FICS's system of ivars.
On FICS you need "set seek 1" to get notification of seek-ad placement, and "iset seekremove" for notifications of removal. In fact it is annoying that this the latter is an ivar, as the interface locks the ivars after connecting, so the user cannot interactively switch on or off the auto-refresh of the seek graph: this only affects appearance of new ads, but not removal of expired ones.
In the ICS code both functions are controlled by "set ads 1/0", and the "seek" var, mentioned in its help files, simply does not exist! In addition, the notification message given for removal of a seek ad is different (but similar in concept: message + ad number).
The easiest fix is probably to change the removal message on ICS to what FICS uses ("Ads removed: #"), and to define "seek" as a synonym for "ads" in the list of vars. Then WinBoard's "iset seekremove 1" will be simply ignored, and removal notification will always automatically accompany placement notification, under control of the "set seek 1" WB sends when connecting.