OK, I am back from Greece, so I had access to my Linux system again.
I started pushing all the WinBoard fixes I had accumulated in the mean time
to hgm.nubati.net (hgmaster branch), after syncing with Savannah.
There seems to e a problem, though, with the file browser. I suspect this
is a side effect of some of the general changes of the text widget settings
done for the internationalization, as the git log shows now changes in the
browser file, and the probem is definitely new:
If I use the browser through a browse button in another popup, (e.g. the
for setting the tournament file in the Match Options dialog), it seems to only
copy the first character of the selected file name to the file-name field.
I put some debug prints in the browser, and it seems the problem occurs
in SFsetText() in path.c, in this piece of code:
text.firstPos = 0;
text.length = strlen(path);
text.ptr = path;
text.format = FMT8BIT;
XawTextReplace(selFileField, 0, strlen(SFtextBuffer), &text);
XawTextSetInsertionPoint(selFileField, strlen(SFtextBuffer));
This code is called when one clicks a filename in the lists in the browser
window,
the clicked text being passed to it as 'path'. selFileField is the
uppermost text widget
in the browser window, and the purpose is to load it with the clicked text.
Now what happens is that 'path' is OK: when I print it, it prints the
complete clicked text,
and acknowledges the correct length of it in text.length. However, when I
print the
contents of SFtextBuffer after the XawTextReplace, it only prints the first
character.
Now SFtextBuffer is the 'use-in-place' string that is supposed to be in
selFileField.
On the display I see that the selFileField widget contains the complete
filename,
but it seems to be stored in the provided buffer array in a format that the
rest of the
code no longer understands. The InsertionPoint is set after the first
character, which is
aready suspicious. It seems like the buffer does not store the text in an
8-bit encoding,
leading to null bytes in between the characters, which the rest of the code
interprets as
end-of-string.
Other minor weirdnesses I observed are:
*) The browser seems to use a fixed-width font in its lists (but not in the
text widgets).
*) The background of the font in all text widgets of al dialogs is now
light gray. (I don't know
if this was intentional or even if it is desirable; I just noticed that it
was different than before.)
_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard