使用C#的Mono技术如何将WinForms界面转换为Cocoa界面？（或者转换为默认的OS X界面）

Question

我有一个C#应用程序，我已经成功地通过Mono在OS X上运行。应用程序本身可以正常运行，但是在OS X上运行时并不是很好看。按钮字体看起来很锯齿，而且许多Windows 7版本中的默认功能也不存在。对我来说，它看起来像一个Win98应用程序，上面贴了一个OS X的上边框。

我正在考虑可能学习Objective-C，这样我就可以编写“正确”的OS X应用程序，但目前我希望能够在苹果设备上运行我的项目，而不必让它们看起来像是拼凑在一起的。 是否有可能将WinForms应用程序转换为Cocoa？Cocoa是正确的界面吗？ 如果可能的话，最好的方法是什么，你们中有没有人知道一个好的教程/写作过程的文章可以让我开始学习？看到实际演示过程会很好。我从例子代码和简短的解释中学到的比从通用文章中学到的更多。

再次感谢！

- Sootah

---

http://www.facebook.com/album.php?aid=94481&id=1500469566&l=85716508e7 - Andrew J. Brehm

希望 Facebook 的链接能够正常工作。它展示了一个 WinForms 应用程序被移植到 Cocoa 的例子。 - Andrew J. Brehm

Answer 1

如果您想创建一个类似于本地的OSX应用程序，您需要使用Cocoa。如果您仍然想使用C＃，可以使用MonoMac。

MonoMac允许您在OSX上本地构建GUI（实际上使用由Apple提供的Interface Builder），但允许您使用.Net / C＃编写应用程序。这样，您可以继续使用现有的应用程序逻辑，只需更改GUI代码即可。

- jpobst

Answer 2

几乎普遍认为，移植的应用程序总是会像移植的应用程序一样。即使是拥有巨额预算的大公司也无法做得更好（我引用Adobe-多么混乱）。

在Windows应用程序端口上贴上Mac外观将显示它的接缝。如果您希望应用程序的行为像本地应用程序一样（并利用平台提供的性能相关好处），则绝对最佳方法是使用建筑文档、规格和要求 - 我知道您已经有了这些-严谨的开发人员 - 根据本地平台自适应设计。这就是Cocoa Frameworks（API），它们用Objective-C（语言）编写。

没有其他路径可以不以垃圾般的外观和由于端口程序员不熟悉目标平台而导致的行为问题来结束。这不仅限于Mono / C＃-to-Cocoa / Obj-C。相反，Java-for-PlatformA-to-Java-for-PlatformB桌面应用程序的端口也存在这些问题。如果您想获得最佳用户体验，请从坚实的架构开始，并为平台构建。

话虽如此，您已经通过意识到这一点并希望做得更好而领先一步。太棒了！虽然我不知道这条路径是否有任何教程，但即使如此，我建议这也不是正确的方法，因为您表示正在寻求质量。利用许多Cocoa书籍和更多在线社区（例如本论坛），在承诺Cocoa-adapted架构和代码库之前学习平台。

根据评论辩论更新

明确一点：我并不是说没有方法或没有工具可以实现。我看到了很多，但不记得，并且不会费心谷歌。我的观点仍然存在：OP关心本地外观的质量（我假设行为和可能的性能），而端口工具/翻译层由于平台架构和用户体验惯例的固有差异而无法实现。 OP怀疑最好学习该平台并专门为其构建，而我同意。您的看法可能不同。达到它。

- Joshua Nozzi

---

看看这个问题：“是否有可能将WinForms应用程序转换为Cocoa？ Cocoa是正确的接口吗？”假设实际模型和业务逻辑与WinForms应用程序分离，完全可以在Obj-C＆Cocoa重新实现的视图下重复使用它。双赢：重要的C#部分被保留，没有人会知道它不是一个完全本地的应用程序。在这里：http://fallingcanbedeadly.com/posts/about-nsducttape P.S.许多仅限于Mac的“完全本地”的Cocoa应用程序也使用C / C ++进行Obj-C的模型和业务逻辑处理。 - Joel Day

@Joel: 关于你的链接，这归根结底还是“可以实现”，但魔鬼在于细节。正如原帖所暗示的那样，使用任何形式的翻译/适配层都存在许多陷阱。不合理地期望直接从架构到架构进行功能和行为映射，这就是你在使用这样的应用程序时感觉“这看起来像是一个糟糕的移植”的原因。 - Joshua Nozzi

@ Joel 关于你的 PS：即使 WebKit 本身也是基于 C ++ 框架的 Objective-C 薄层 ;) - Yuji

我不同意你的说法，认为必须重写整个应用程序才能实现良好的本机接口。无论背后的代码是C#、C++、C、Obj-C、Java或其他任何语言，你都可以拥有出色的本机Mac接口；而即使所有代码都是'纯'的Objective-C，也同样容易拥有可怕的非Mac风格界面。 - Coxy

假设用户体验被改变以遵循平台指南，本地AppKit控件用于UI，所有依赖项都包含在应用程序包中，并且使用像~/Library/Preferences这样的标准目录等，我真的怀疑任何人会注意到底层业务逻辑是用Obj-C之外的语言编写的。如果用户体验无缝，客户满意并且OP免受大量重复努力的困扰，每个人都是赢家。 - Joel Day