delphi - Kylix做错了什么？

Closed. This question is opinion-based。它当前不接受答案。












想要改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。

7年前关闭。



Improve this question




关于Delphi团队致力于跨平台开发的所有讨论，不断出现的一种感觉是:“我希望他们这次能做到这一点，而不是像Kylix那样。”我当时并没有真正注意到Kylix，因为Linux当时还不如现在成熟，并且它并不是我感兴趣的操作系统。所以现在它又开始成为一个问题，我发现自己想知道，Kylix做错了什么，CodeGear这次如何做得更好？

最佳答案

至于这次CodeGear可以做得更好的地方是:

需要在对话框中布置控件的方式更加抽象，而不是VCL现在使用的基于像素的东西。这在已经具有高DPI设置或非标准字体的Windows上会崩溃，对于多平台程序而言，情况将更加糟糕。例如sizer classes in wxWidgets或GTK，Java或QT中的布局类/管理器-它们在更改字体或控件大小方面都做得更好。另一个优点是，透明控件在翻译的文本变短或变长时可以透明地工作。

使库仅Unicode。理想情况下，将有一个特殊的字符串类，在Windows上内部使用UCS-16，但对于Linux和Mac OS X使用UTF-8。程序应该能够使用平台 native Unicode编码，而不必强制进行转换。每个文件系统访问或屏幕输出。但是也许他们已经用Delphi 2009的Unicode字符串更改将球投到了那个球上。

GUI应该在所有平台上使用 native 控件，以使和外观正确。那将是Windows，Mac上的Cocoa和Linux上的标准控件，理想情况下，它应该使用GTK或QT，具体取决于桌面是GNOME还是KDE。

远程调试器需要成为一流的工具，而不是现在的 bug 和半隐藏的东西。针对不同平台的开发通常在VM中进行，有时只有对计算机的远程访问。