Mas*_*ler 9 delphi cross-platform
随着关于Delphi团队致力于跨平台开发的所有讨论,一种不断涌现的情绪是,"我希望他们这次做得对,不像Kylix." 我没有真正注意到Kylix何时出现,因为当时Linux并不像现在那样成熟,而且它不是我感兴趣的操作系统.所以现在它又开始成为一个问题,我发现自己在想,Kylix做错了什么,这次CodeGear怎么能做得更好呢？
至于CodeGear这次能做得更好的事情:
需要一种更抽象的方法来在对话框中布置控件,而不是VCL现在使用的基于像素的东西.这已经在具有高DPI设置或非标准字体的Windows上出现故障,对于多平台程序来说会更糟糕.以wxWidgets中的sizer类或GTK,Java或QT中的布局类/管理器为例- 它们在更改字体或控件大小方面都做得更好.作为另一个优点,这可以透明地与控制中的翻译文本更短或更长.
使库只有Unicode.理想情况下会有一个特殊的字符串类,在Windows内部使用UCS-16,但在Linux和Mac OS X上使用UTF-8.程序应该能够使用平台本机Unicode编码,而不是强制转换为每个文件系统访问或屏幕输出.但也许他们已经通过Delphi 2009的Unicode字符串更改丢弃了那个.
图形用户界面应该在所有平台上使用本机的控制,进行适当的外观和感觉.那将是Windows上的标准控件,Mac上的Cocoa,以及Linux上理想情况下应该使用GTK或QT,具体取决于桌面是GNOME还是KDE.
远程调试器需要成为一流的工具,而不是现在的错误和半隐藏的东西.不同平台的开发经常发生在VM中,有时只能远程访问机器.
我当时(仍然)在Free Pascal Unix RTL上工作,在Kylix之前在*nix上做了Pascal,我们从第一个测试版开始就密切关注它.所以可以说我对Kylix的兴衰有一个很好的独特视角.
一个主要的问题是它不适合服务器应用程序使用,当时人们在Linux上做的主要事情,但恕我直言,并没有解释失败.
虽然存在各种其他问题(Wine,部署,非常以Linux/x86为中心,因此难以移植到"下一个"*nix,Borland没有足够推动它),我仍然认为Kylix失败的事实更像是一个证明Linux当时的困境不是Kylix问题的直接结果.其中一些(如长期二进制API稳定性)尚未得到修复.
尽管如此,它本应该起到恕我直言的作用,因为它明显领先于其他部分,并且可行,如果需求真的存在,人们会加强(有些人,我们仍然会在FPC列表中获得月度人员转换大型Kylix代码库).
一个面向服务器的版本可能会受到更大的打击,并且他们在单一来源的东西上做得太过强烈(这错误地提出了期望),但仍然是GUI原则,因为它本应该起作用恕我直言,我责怪Linux和Linux市场.市场太过激烈,并且在Windows模型之后还没有为商业化做好准备.