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. _______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
