将WPF移植到Cocoa (反之亦然)

Question

我正处于为未来mISV创建软件的开始阶段。该程序是一个桌面应用程序，从长远来看，我希望有一个本地版本的Windows和OS (我已经看过各种跨平台的API，但没有一个符合我的需求)。最初，我不认为同时为两个平台进行开发是有意义的。考虑到这一点，我一直在研究Windows的WPF和OS X的Cocoa，它们看起来很相似。

有没有人有过将一个移植到另一个的经验？是否有特定的技术/范例可以让移植变得更容易？忽略业务考虑，您是否建议先在其中之一上进行开发？

Answer 1

我目前在这个领域从事移植工具的working工作，有多年在Mac和Windows上使用或编写跨平台框架的痛苦经历。

过去最大的问题之一是苹果拒绝开放Cocoa的nib格式(Carbon nib在几年前就是开放的XML文件)。随着XCode 3和.xib格式的出现，这一点发生了变化，Frasier Speirs对此也进行了解释。

至少在基本布局级别，现在有机会自动从一种XML格式移植到另一种格式。我认为WPF (XAML)更干净，所以我使用它作为我的基本格式，并迁移到Cocoa。

当涉及到后台代码时，虽然你可以在Mono下使用C#，但CocoaSharp项目似乎要么停滞不前，要么非常慢，我不推荐这样做。

如果您对C++感到满意，可以考虑在C++中使用尽可能多的逻辑，在C#和Objective-C中使用一个薄的特定于平台的层。

另一种值得研究的方法是使用动态语言，如Python或Ruby。我不确定目前IronPython和IronRuby中哪一个更成熟，但现在两者都得到了微软人员的支持。在Cocoa方面，我认为Ruby语法的灵活性将会取得胜利，RubyCocoa很可能会超过PyObjC。

否则，在C#和Objective-C中工作，并维护两个完全独立的具有相同设计的代码库。幸运的是，这些框架对大多数东西都有类似的语义，特别是在使用绑定的情况下。

Answer 2

井。一旦你为Cocoa编写了一个应用程序，就可以将它移植到Windows上。这可以使用gnustep或Cocotron来完成。

如果您采用另一种方式，那么WINE将使移植变得更容易。

我宁愿先写OSX版本。这是因为Windows用户不清楚他们想要的应用程序是什么样子的。根据我的经验，他们可以忍受各种各样的用户界面。一致性对他们来说价值不大。由于Windows应用程序应该是什么样子的，没有什么共识，没有什么能阻止Windows用户真正喜欢OSX设计，他们甚至经常这样做。用于windows的iTunes看起来像是一个非常典型的OSX应用程序，你很少听到有人抱怨它不够像Windows。

从另一个方向来看，这不是真的。OSX用户对Cocoa应用程序有明显的偏好，对像GIMP或Inkscape这样的东西很难容忍，这些东西在OSX下工作得和在其他地方一样好，但在OSX训练有素的人看来显然很丑陋。

Answer 3

我认为通过选择特定于每个平台的窗口环境，您走在了正确的道路上。这种方法允许您在每个平台上创建不受跨平台窗口工具包固有折衷限制的用户体验。

好的第一步是把你的设计分成两部分:平台特定的元素和平台无关的元素。您已经可以将任何UI代码放入特定于平台的列中，但是您的应用程序可能需要一些可以用与平台无关的C++编写的数据持久性。通过这种方法，您可能会发现，可以以平台中立的方式编写相当多的逻辑和基础设施，只留下UI和粘合代码作为特定于平台的代码。

Late Night Cocoa最近有一集节目名为。你的应用程序可能不够“大”，但这个播客给了一些做过几次的人相当多的移植知识。