[fpc-devel] Unicode support (yet again)

[Mattias Gaertner]

On Thu, 15 Sep 2011 19:00:35 +0200
Felipe Monteiro de Carvalho <felipemonteiro.carvalho at gmail.com> wrote:

> On Thu, Sep 15, 2011 at 6:01 PM, Mattias Gaertner
> <nc-gaertnma at netcologne.de> wrote:
> > It seems to me, that all of the above functions and classes could be
> > solved for applications using UTF-8 ansistrings with a special
> > widestring manager and filefunction manager, right?
> 
> Theorically, it could, but it would work only in the Ansi RTL,
> basically it would not work at all in the Unicode RTL and LCL users
> would be locked out of it.
> 
> And I say more, two RTLs will immediately cause problems in all kinds
> of libraries.

Any change of RTL types does.


>[...]
> This is not a stable solution, for Lazarus I see only 2 stable
> solutions assuming that my proposal is completely off the table:
> 
> 1> Migrate to UnicodeString
> or
> 2> Implement everything that we need in the LCL to substitute RTL
> routines which include string or file handling (and we are not really
> that far away from finishing that at all...)

Yes.
Or 3 - migrate LCL to UTF8String

 
> Porting all of the libraries and applications which I use for
> UnicodeString will likely be so huge of a task that I don't see any
> feasability in this kind of thing. We need to port SynEdit, the LCL,
> fpvectorial, regexpr... lots of applications which I wrote and nearly
> all of them do some kind of text parsing or handling...

Same here.

 
> Even worse would be keeping all those projects with IFDEF UNICODE
> everywhere ... Just imagine how many regressions linked to not testing
> both possibilities...
> 
> Just implementing ourselves what we need for file handling is orders
> of magnitude less work for me, and then Lazarus can work regardless of
> which RTL packages rely on, either Ansi or Unicode.

The LCL uses TStrings. If TStrings is changed to another string type,
then the LCL must follow or define its own class.


Mattias