Felipe Monteiro de Carvalho wrote:
On 10/16/06, Marc Weustink <[EMAIL PROTECTED]> wrote:
IMO there are 2 ways to solve this:
1) make 2 separate widgetstes. Im' not really pro this since it is hard
to maintain and causes a lot of duplicate code. We don't want the same
ifdef mess we have with gtk1/2 again.
2) Load the functions at runtime. So if the W function is available use
that otherwise use the A function.
Option 2 doesn't fix the problem that then we will no longer have a
Ansi IDE, and all old projects doing internationalization will
immediatly get broken, because old .lfm and .lrs files contain Ansi
encoding, and the new ones will be utf-8, and the new ones may take a
long time to work.
Our main widgetsets today only work with ANSI, I think it will be too
hard on the users if we just abandon ANSI support like option 2 would
do.
No, on windows they work with ansi, on linux it it is just what is
specified a s LANG. No conversion is made.
Option2 only speaks about the API to be used. IMO all internal LCL
communication should be done the same way. I would prefer utf8 for that.
Maybe the win32 widgetset needs to be prepared for cross-platform
before we start working on this. And split in a Base and 3 subwidgets
(wince, win32 and win32u). One Idea I have would be to concentrate all
code with U or A versions on some include files, and each subwidget
can write it's own files.
wince and win32,win64 yes, but not a separate winu.
But then we hit the problem that this is a huge task, that would
probably delay 1.0 a lot.
IMO this is post 1.0
(The internal format used in writing lfms is pre 1.0 I think)
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
