If I move the board window during a game while the stickyWindows option is
actice, the clock for the player who has the move will most often - but
not always - stop.
Yes, I can reproduce that in Two-Machines mode.
The same happens if the window is iconified and deiconified.
I tried to find the reason but failed. But I made the following 2
observations:
1) The window actions will trigger the function DelayedDrag() if
stickyWindows is active, and DelayedDrag() uses XtAppAddTimeOut() like
also the clock does. Could it really be that no more than one timer can be
active?
I am pretty sure that is not the case. ScheduleDeayedEvent uses
XtAppAddTimeOut, and some scheduled events (e.g. for the -keepAlive option)
also run in parallel with the clock. And I remember that for some delays I
could not use ScheduleDelayedEvent because it would erase another event.
(ScheduleDelayedEvent can indeed only be used once.) These then started to
work without problems when I made them call XtAppAddTimeOut directly.
Finally, like you say, the clock does not always stop, while in a clocked
game there should always be one clock-tick event pending.
So it seems we unreliably lose events or commands from/to the X-server. I
guess this could in principle be caused by improper XSync or XSynchronize
calls: it seems the second argument of those can cause clearing of the
event queue?
2) The function ClockTimerRunning() is defined, but never called. I
suppose it should be deleted.
I guess we could. But it small, and you never know if it could be useful in
the future. So why bother.
_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard