Re: [Bug-XBoard] Latest developments

[h.g. muller]

> BTW. I cannot compile the git master branch right now:
>
> $ LANG=C make backend.o
>   CC     backend.o
> backend.c: In function 'HandleMachineMove':
> backend.c:7964:82: error: macro "N_" passed 7 arguments, but takes just 1
> backend.c:7963:40: error: 'N_' undeclared (first use in this function)
> backend.c:7963:40: note: each undeclared identifier is reported only once 
> for each function it appears in
> backend.c:7964:83: error: expected ')' before ';' token
> backend.c:7970:2: error: expected ';' before '}' token

This is weird. Especially since the above error messages seem completely 
non-sensical. When I print backend.c from the current master branch in the 
savannah repository, There is no N_ macro anywhere near that line number. 
(It is in HandleMachineMove, though):

7956         if(cps->alphaRank) AlphaRank(machineMove, 4);
7957         if (!ParseOneMove(machineMove, forwardMostMove, &moveType,
7958                               &fromX, &fromY, &toX, &toY, &promoChar)) {
7959             /* Machine move could not be parsed; ignore it. */
7960           snprintf(buf1, MSG_SIZ*10, _("Illegal move \"%s\" from %s 
machine"),
7961                     machineMove, _(cps->which));
7962             DisplayError(buf1, 0);
7963             snprintf(buf1, MSG_SIZ*10, "Xboard: Forfeit due to invalid 
move: %s (%c%c%c%c) res=%d",
7964                     machineMove, fromX+AAA, fromY+ONE, toX+AAA, 
toY+ONE, moveType);
7965             if (gameMode == TwoMachinesPlay) {
7966               GameEnds(machineWhite ? BlackWins : WhiteWins,
7967                        buf1, GE_XBOARD);
7968             }
7969             return;
7970         }


I am glad the clock bug seems to have gone away. I really could not find 
anything wrong remaining.

During rewriting the file browser in my 'refactor' branch, I stumbled on a 
another problem, and I am not sure if v4.6.x is currently free from that. I 
got very erratic behavior as to which became the active window after pop-up 
or pop-down of dialogs. I remember I had problems with that before, but I 
thought they went away after I popped up file-browse and error-popup shells 
as children of the dialog that had focus, rather than as children from the 
main window. This, however, seemed no longer sufficient when I used 
GenericPopUp to generate the file-browse dialog:

When I invokes it from the Browse button of a dialog (say Match Options), 
the first time it popped up on top (as it should). But after closing it, 
focus revert to the main board, rather than the Match Options dialog, 
although I created it as a child of the Match Options shell. And even 
worse, if I invoked it again from the Match Options dialog after that, it 
would consistenly pop up in the background (often completely invisible), 
while the Match Options dialog would retain focus and stay on top. This 
always happened after the main window had obtained focus once.

No amount of XtSetKeyBoardFocus, XSetFocus, or even XRaiseWindow could 
alter that pattern.

After some Googling, I found that it is a known problem that XRaiseWindow 
does not work on Gnome. Presumably the Xaw routines to create and popup 
windows suffer from that as well. It seems to have something to do that 
XRaiseWindows cannot be used to raise windows of another application, and 
that Xaw apparently does not tell the window manager to which application 
the windows belong, so that it assumes they are from different 
applications. I dug up some code that seems to achieve the raising by 
sending a _NET_ACTIVE_WINDOW message to the root window. To get my 
file-browser rewrite work aceptably, this was essential. I wonder if it 
would be needed to port this to 4.6.1.