On Tue, Dec 24, 2013 at 3:18 AM, Hans-Peter Diettrich <[email protected]> wrote: > Marco van de Voort schrieb: >> >> On Mon, Dec 23, 2013 at 06:52:21PM +0100, J?rgen Hestermann wrote: >> >>> Am 2013-12-23 11:32, schrieb Marco van de Voort: >>> > So I would say UTF16, and maybe, if there is demand, some can get utf8 >>> :-) >>> >>> The question is: >>> Should FPC and LCL use a fixed encoding for all platforms >>> or should the encoding be adapted for each WidgetSet/OS? >> >> >> Not necessarily. Supporting both on both platforms is a sane reason too. >> >> One can't ditch utf16 because of Delphi compatibility. It will be hard to >> ditch utf8 because of old Lazarus compatibility. > > > In the meantime we have 2 Delphi compiler/RTL versions: > - Ansi (Win32) > - Unicode (UTF-16, multi target) > and 4 GUI versions > - VCL Win32 > - CLX > - VCL.NET > - FireMonkey > summing up to 8 versions in theory, and 3 versions in practice. > > So what does "Delphi compatible" mean *really*? > > The FPC compiler supports multiple targets, and most probably can be managed > to support both string types using the *same code base* (maintenance > issue!). IMO this does *not* apply to the libraries (RTL and LCL) and > existing applications, where Lazarus counts as the most important and > prominent application. We can be happy to have one single LCL and IDE > version, which is already incompatible due to the use of UTF-8 strings > instead of Ansi. Multiple versions, for compatibility with the other Delphi > combinations, are beyond *development capacities*. > > This sheds a very different light on Delphi compatibility, meaning that a > Unicode LCL and IDE can *not* be supported in parallel to the existing UTF-8 > implementation. Dumping UTF-8 would discontinue support for the *entire* > range of *existing* LCL applications, i.e. loose all the current Lazarus > users :-( > > So what should be the intended *audience* for a future Lazarus version? > > IMO the biggest group are old fashioned Delphi (D7) users, which want their > existing Ansi/VCL code base supported *without* complications and > incompatibilities introduced by the newer Delphi versions. The subject of > this thread clearly indicates that UTF-8 is *not* a solution for this group > of users.
I started this thread. My problem isn't to use UTF-8 on Windows... my problem is use different encodings on the same code, ie, RTL <> LCL. Use functions, always, to convert string between RTL and LCL and vice-versa IHMO is wrong because the final code is confusing. In a huge application you still need to think "here is UTF-8 or ANSI/UTF-16?" > Another important user group is targeting mobiles, where time will tell > whether FM will ever succeed, or shares the fate of Kylix or VCL.NET. IMO > these should be happy already with fpGUI or mseGUI, no need to raise another > competitor in this area. > > > >> But if I have to chose to kill one, it is utf8. It is the lesser used >> choice >> for unicode strings INSIDE APPLICATIONS. Yes, UTF8 is dominant in >> documents, but >> not in APIs. > > > That's my conclusion as well. But is that new audience worth to abandon the > entire existing Lazarus audience? Of course nobody will abandon the entire existing Lazarus audience. If the RTL will be UTF-16, UTF-32, whatever the Lazarus will continues -- I think -- working using UTF-8. Marcos Douglas -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
