All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vesa Jääskeläinen" <chaac@nic.fi>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [Fte-devel] unicode support
Date: Sun, 19 Feb 2006 23:05:34 +0200	[thread overview]
Message-ID: <43F8DD9E.4020403@nic.fi> (raw)
In-Reply-To: <1140362299.14276.188.camel@hurina>

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	other threads:[~2006-02-19 21:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1140362299.14276.188.camel@hurina>
2006-02-19 21:05 ` Vesa Jääskeläinen [this message]
2006-02-20 11:57   ` [Fte-devel] unicode support Marco Gerards
2006-02-20 22:26     ` Vesa Jääskeläinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43F8DD9E.4020403@nic.fi \
    --to=chaac@nic.fi \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.