Hash: SHA1

I've spent this weekend moving into my new apartment, and I don't have internet for my desktop yet (on my laptop I'm "borrowing" the upstairs neighbor's wireless for the time being). However, when I get a chance I will set up ter'angreal to compile in unicode mode on Debian; I'll let you know how it goes.

I tried compiling in unicode on Windows once, and it failed miserably because Crystal Space can't (or couldn't) handle the Unicode/wide-character versions of the win32 API. So I'm not sure what the status of unicode on Windows is going to be, it may or may not be possible to isolate the unicode-using wxwidgets from the rest of CS. Debian doesn't have this problem because the standard encoding is UTF-8, which is backwards-compatible with ASCII.

A related, larger issue is internationalization of VOS in general. I'm not sure where to go with that, although Reed mentions one issue which is including the text encoding in places like property datatypes and talk messages. We would also want to use gettext to support translations for the UI of user apps like Ter'Angreal.

I should be getting internet set up at my apartment on thursday, so I'll be able to start working on VOS again. In the mean time I need to finish unpacking :-)

On Sun, 4 Sep 2005, Reed Hedges wrote:

I guess wxgtk 2.6 in Debian is built in Unicode mode, and while I
noticed some random bits and pieces of TerAngreal with stuff in #ifdef
wxUSE_UNICODE conditionals, and some wxStrings are converted with
wxString::mb_str(), it's generally incomplete.

If build in Unicode mode, wxChar is a wchar_t, otherwise it's an 8 bit
char.  Wx provides some objects to convert between char* in various
encodings, and wxChar (whichever of the above it might be).  So I think
to create a wxString from an ASCII char* you do this:

 const char* cstr = "foo";
 wxString wxstr(cstr, wxConvUTF8);

In Unicode mode, wxString uses the predefined wxConvUTF8 object to
convert cstr from UTF8 (ASCII) to Unicode.  In non-unicode mode it just
uses cstr, or maybe wxConvUTF8 actally does no conversion... whatever.

And to get a UTF8 string:

 cstr = (const char*) wxstr.mb_str();

Again, in Unicode mode, mb_str() converts to ASCII, while in non-unicode
mode it just returns the ASCII string.  Maybe you need to do this, not
100% certain yet:

 cstr = (const char*) wxstr.mb_str(wxConvUTF8);

And of course string literals have different syntax, wx provides the wxT
macro to do the right thing depending on the mode (though for the most
part we are already using that in terangreal).

I made a few changes along those lines and got wxterangreal to build but
now it crashes in CS, as does wxtest, in csDriverDBReader.

Has anyone else been hacking on Terangreal to build in unicode mode?
Anyone want my patch while I figure out why it's crashing? (I suspect
that some combination of my graphics hardware and X configuration is
revealing the crashing bug)  I have a bunch of other modifications I
made to terangreal mixed in at the moment, though, I'd have to seperate

One thing we will need to do is add support for different encodings to
things like the talkative message strings and property values.  Or maybe
just change them to always use unicode?


[   Peter Amstutz   ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
Version: GnuPG v1.4.1 (GNU/Linux)


vos-d mailing list

Reply via email to