grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fte-devel] unicode support


From: Vesa Jääskeläinen
Subject: Re: [Fte-devel] unicode support
Date: Sun, 19 Feb 2006 23:05:34 +0200
User-agent: Thunderbird 1.5 (Windows/20051201)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]