To: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Cc: unison-users at yahoogroups.com, lablgtk at kaba.or.jp
Subject: Re: LablGTK/Windows and locale<->utf8 conversion
References: <20020825091217U.garrigue at kurims.kyoto-u.ac.jp>
	<adjbb5bn.fsf_-_@mail.ru>
	<20021224114705D.garrigue@kurims.kyoto-u.ac.jp>
From: Dmitry Bely <dbely at mail.ru>
Date: Tue, 24 Dec 2002 23:12:55 +0300
In-Reply-To: <20021224114705D.garrigue at kurims.kyoto-u.ac.jp> (Jacques
 Garrigue's message of "Tue, 24 Dec 2002 11:47:05 +0900")
Message-ID: <1y479nw8.fsf at mail.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp> writes:

>> As you probably know, GTK+ 1.3 for Windows (and GTK+ 2.0 on all platforms)
>> uses Unicode internally, while Ocaml itself uses ASCII codepages and
>> locales. So under Windows we should convert all strings before passing them
>> to LablGTK functions. (I recently discovered that when I tried to find out
>> why Unison cannot correctly show Cyrillic file names under Windows. Unison
>> people just hard coded the conversion always assuming the codepage
>> 1252). So my question is: maybe integrating the transparent locale<->utf8
>> conversion directly into LablGTK would make sense? IMHO it should be
>> simple: just add g_utf8_to_locale()/g_free() and
>> g_locale_to_utf8()/g_free() calls to all marshalling.
>
> We just bumped into the same problem with the Gtk2 port.
> So the answer is that there will be some support for conversion to and
> from utf8 in lablgtk2, and it would be a good idea for unison to use
> lablgtk2 when it becomes stable enough.
>
> Handling unicode as a special case for windows in lablgtk1 would be
> cumbersome, so it will have to wait for lablgtk2.
>
> As for making it automatic, I have still doubts about the locale
> approach.

Maybe to add to some configuration options to lablgtk, that will specify
(among other things) if the Unicode <-> ANSI conversion is necessary
between lablgtk and the user code?

> Actually, you might want to use several character codes in
> the same program, and even use unicode characters in caml (btw, ucs4
> is 31-bit wide, which seems nice). Also, glib has some special
> functions for converting file names on windows, which seems to mean
> that conversion may be subtle. So in the beginning conversions will be
> left to the user.

Thank you for the explanation. OK, I will made a patch for the Unison
side.

- Dmitry Bely