Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h.g. muller]

At 00:09 9-6-2011 -0700, Tim Mann wrote:
> * The file browser uses a somewhat kludgey feature (useStringInPlace) that 
> doesn't work the way it's expecting if its widgets inherit international = 
> True from the resource database. In the international case, the AsciiText 
> widget keeps its internal string representation in UCS-4 (32-bit wide 
> character) format. Normally that doesn't matter, but if you say 
> useStringInPlace, the in-place string you are looking at is also in 32-bit 
> wide character format. The existing code is expecting null-terminated 
> strings of 8-bit bytes.
>
> It should be possible to fix the above temporarily by turning off 
> international for just the affected widget(s) in the file browser, but I 
> don't have that working yet for some reason.
>
> This isn't a good permanent solution because it means the file browser 
> (still) won't be able to handle filenames with characters above 0x7f. 
> Well, or maybe it can handle ISO8859-1 characters up to 0xff -- I'm not 
> sure -- but definitely not general Unicode utf8 filenames.
>
> * The fixed-width font in the directory lists happens because draw.c looks 
> for the "font" resource and falls back to 9x15 is there is none. Since we 
> are only setting fontSet now and not font, it uses the fallback now. We 
> could probably improve this by taking the first font out of the 
> messageFont fontset and setting it as "font", similarly to what I did with 
> coordFont. That still leaves the code not handling international 
> characters in directory names.
>
> The lists look like more work to internationalize properly because of the 
> explicit character drawing in draw.c -- they don't use Xaw text widgets 
> for some reason. Maybe doing it this way is more efficient and that 
> mattered on the slow computers years ago when this code was written.
>
>   --Tim

OK, so the file browser sucks in multiple ways, and we should probably not 
waste too much time on it. It is not really part of XBoard, and I did not 
like the user interface of it very much anyway. GTK will come with its own 
file browser, I suppose.

It is very inconvenient that the browser now doesn't work at all, though. 
Perhaps we can overrule the resource-database setting for this single 
useStringInPlace widget, and set international = False there, for the time 
being. I don't mind the fixed-width fonts so much, that is still workable, 
so we can ignore the font problem.

The way the XBoard front-end has evolved by now, it shouldn't be very 
difficult to provide our own browser dialog from scratch, using the 
GenericPopup routine. I could define a dialog with two single-line text 
widgets for the file name and the extension filter, a large multi-line text 
widget for the (filtered) directory contents, and the standard OK & cancel 
buttons. The only thing that would really have to be programmed is a 
callback for clicking in the contents widget, which should either transfer 
the clicked name to the filename widget (if it is a file), or change to the 
clicked directory (possibly "..") and refresh the list. 
Internationalization should then automatically work, like in all other 
dialogs. I will have a look into it next week.