To: dbely at mail.ru Cc: unison-users at yahoogroups.com, lablgtk at kaba.or.jp Subject: Re: LablGTK/Windows and locale<->utf8 conversion In-Reply-To: References: <20020825091217U.garrigue at kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021224114705D.garrigue at kurims.kyoto-u.ac.jp> Date: Tue, 24 Dec 2002 11:47:05 +0900 From: Jacques Garrigue Lines: 33 From: Dmitry Bely > 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. 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. Cheers, Jacques Garrigue