From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1FAvmL-0000Wm-Fe for mharc-grub-devel@gnu.org; Sun, 19 Feb 2006 16:07:37 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FAvlx-000061-RH for grub-devel@gnu.org; Sun, 19 Feb 2006 16:07:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FAvlW-0007zI-J5 for grub-devel@gnu.org; Sun, 19 Feb 2006 16:06:49 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FAvkD-0007TW-D4 for grub-devel@gnu.org; Sun, 19 Feb 2006 16:05:28 -0500 Received: from [157.24.2.30] (helo=smtp1.cc.lut.fi) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FAvq5-0005UT-No for grub-devel@gnu.org; Sun, 19 Feb 2006 16:11:30 -0500 Received: from localhost (smtp1 [127.0.0.1]) by smtp1.cc.lut.fi (Postfix) with ESMTP id 1096D70166 for ; Sun, 19 Feb 2006 23:05:22 +0200 (EET) Received: from smtp1.cc.lut.fi ([127.0.0.1]) by localhost (smtp1.cc.lut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24133-06 for ; Sun, 19 Feb 2006 23:05:21 +0200 (EET) Received: from [192.168.1.100] (lk4-a-4-1.lnet.lut.fi [157.24.102.107]) by smtp1.cc.lut.fi (Postfix) with ESMTP id 77FCA70132 for ; Sun, 19 Feb 2006 23:05:21 +0200 (EET) Message-ID: <43F8DD9E.4020403@nic.fi> Date: Sun, 19 Feb 2006 23:05:34 +0200 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: The development of GRUB 2 References: <1140362299.14276.188.camel@hurina> In-Reply-To: <1140362299.14276.188.camel@hurina> X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by lut.fi Subject: Re: [Fte-devel] unicode support X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 21:07:35 -0000 Timo Sirainen wrote: > Starting a new thread since I only now subscribed to this list. > > Did you already have some real plans how to start writing the support? > My plan would be: > > 1. Change pretty much all chars to wchar_t. Most of the functions that > FTE uses for handling the char arrays already exist for wchar_t, so it > should be pretty simple to change it, just a lot of work. > > 2. After the wchar_t changes, make FTE work with 8bit files. Just to see > that it's all still working. > > 3. Add support importing/exporting UTF-8 files. Opening could detect > UTF-8 automatically and in "Save as" there could be an option to specify > if UTF-8 should be used or not. I think this also needs some character > set translation library, iconv would be at least one possibility for > UNIX. > > I don't think it's such a good idea to start moving to C++ strings or > wxWindows or any of that yet. Those would be pretty huge changes and I > fear they would just never get finished. I have done steps 1 and 2 in past and perhaps even step 3... you could perhaps still find link to archive containing source to that version... BUT.. it's not that simple in case of fte. It's kinda complex situation, at beginning I though that it would be just easy search'n'replace operation, but after lessons learned, there are just too many places where simple change is not possible. I think last time I was at state that regexp handling were broken (and I am not familiar with that, so I left it alone). I think I spent quite lot of time fixing load/save as FTE's mechanism isn't the cleanest one. If I remember correctly I wrote C++ class for handling Unicode strings to make my day at least somehow easier. Another issue is that you have to support several terminals without braking others. For win32 I think it was quite easy to modify the rendering code, but for Linux there are more to that. Perhaps those libraries have grown better in time, but last time they were a bit brain dead. The problem here is that you can't change only one component, you have to change them all if you want to test it out. So braking it to smaller components was my idea on previous mails. But if you are also willing to work on this it would be nice. I can manage the Win32 specific console code, but we need people for other areas. And that UTF-8 is not the only target formatting we need to think about.