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.
_______________________________________________
Bug-XBoard mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-xboard
