Thanks. Obviously I didn't test enough parts of xboard. The file browser must be doing some things that are a little different from the older code. I'll take a look when I get a chance.
I didn't do anything that was supposed to change the background anywhere. On Wed, Jun 8, 2011 at 11:55 AM, h.g. muller <[email protected]> wrote: > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-xboard >
_______________________________________________ Bug-XBoard mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-xboard
