Java Mac的RCP应用-碳还是可可？

首先，我不是Mac开发者，也是一个非常随意的Mac用户，所以请接受我的问题

我有一个相当大的RCP应用程序，主要针对windows和linux，在这两个平台上都运行良好。现在，我试着在OSX（carbon x86）上运行它，发现它看起来很难看，一点也不像Mac，而且使用起来相当笨拙。例如，这里有一件最简单的事情，我甚至不能让它看起来笔直，无论我做什么，这些按钮都不会按我希望的方式放置：这就是它在windows上的外观，用于比较（相同的代码库）：

它降低了按钮的高度，没有正确放置按钮，对齐混乱等等

这些只是冰山一角，可能还有更大的问题

所以，我有两个问题：

1） 我是否应该用RCP应用程序为在MAC上的存在而奋斗呢？也许这是一条死胡同，没有人真的这么做？毕竟苹果和java没有太多的混合

2） 如果我这么做的话，我应该瞄准碳还是可可？我将期待最新的mac开发。我只喜欢其中一个，你会选哪一个？标准是什么

---

更新：

我为cocoa创建了发行版，所有这些奇怪的渲染问题都消失了。使用eclispe rcp 3.7。一切看起来都很完美

这是一个主观的问题。其他人也这样做吗？当然，有不同程度的投资和关怀。你应该这样做吗？我认为这取决于用户的需求和期望

使用可可粉。旧的Mac OS 9兼容API，而新的Mac OS X API（以前是NextStep API）历史上，Eclipse（以及SWT和RCP应用程序）只支持Carbon，而Eclipse3.4中添加了Cocoa支持。（事实证明，Cocoa事件循环和SWT事件循环很难集成，但苹果公司邀请SWT团队到Cupertino坐下来让它工作。）

也就是说，如果你的应用在这两个平台上看起来非常不同，我会感到惊讶。在一些小部件周围确实存在一些小的UI差异——特别是聚焦环看起来有点不同——但总体而言，您应该能够在碳或可可中进行测试。但作为一种释放工具，我会使用可可粉

作为Eclipse插件（以前是RCP应用程序）上的“Mac guy”，如果您决定投入一些时间改进Mac OS体验，我可以提供一些建议：

这可能值得一读Mac电脑。事实上，没有人（包括苹果公司）将此文件视为牢不可破的法律，但这是将Mac应用程序视为Mac应用程序的一个良好开端。我怀疑HIG会这么说，但在按钮上有图标并不是一件特别像Mac的事情。（它更可能位于工具栏中。）

巴奇拉是你的朋友。当你发现自己的头撞在桌子上，想知道为什么

按钮
和
SWT.ARROW
位在碳上看起来不合适时，最好知道bug注释中可能有一个解决方法。此外，有时会有人发布您可以集成的修复程序（因为作为RCP应用程序，您可以发布自己的SWT版本）。例如，在Mac操作系统中使用的功能首先出现在bugzilla中

Mac OS应用程序往往比Windows或GTK应用程序使用更多的空格。如果您只为Windows和Linux开发，则有一种趋势，即在布局中只关注大量像素的填充和边距。当你在Mac OS上运行这个应用程序时，它看起来会很奇怪，而且会变得杂乱无章。最好根据系统建议设置边距和填充。您可以使用

IDialogConstants

获取这些默认值（在DLU中），然后转换为像素。例如：

int marginW = Dialog.convertHorizontalDLUsToPixels(fontMetrics, IDialogConstants.HORIZONTAL_MARGIN);
int marginH = Dialog.convertVerticalDLUsToPixels(fontMetrics, IDialogConstants.VERTICAL_MARGIN);

int hSpacing = Dialog.convertHorizontalDLUsToPixels(fontMetrics, IDialogConstants.HORIZONTAL_SPACING);
int vSpacing = Dialog.convertVerticalDLUsToPixels(fontMetrics, IDialogConstants.VERTICAL_SPACING);

您可能希望使用一个对话框和复合基类来为您提供这一点，这样您就有了简单的访问器

回想一下，Windows上的“确定”和“取消”按钮是从Mac OS和GTK向后的。

对话框

类处理将默认按钮（确定、是、接受等）放置在正确的位置。如果您开始在对话框按钮栏中放置奇怪的按钮，请务必注意SWT可能会为您重新排序这些按钮

连接键侦听器或加速器时，不要使用控制键。苹果用户可能希望在这种情况下使用命令键（又称苹果键）。对于加速器，只需使用

M1

而不是

CTRL

发布时，将应用程序重新打包到

.app

。Mac用户希望有一个

.app

和里面的资源，他们不希望有一个

.app

文件夹和一堆其他不必要的文件夹。Mac的PDE构建的输出看起来就像其他平台一样——一个包含启动器的文件夹，位于

插件

和

功能

目录旁边。作为构建后步骤，您可以将

插件

和

功能

目录移动到

.app

目录中，并编辑启动器以反映更改。（我认为，互联网上有一个perl脚本，如果没有，我可以发布一个。）

---

谢谢，爱德华，这真是太好了helpful@awoodland谁结束了这个问题？我实际上收到了一个非常有价值的答案，其中有大量的参考资料和实用的专业知识。如果你没有受到干扰，你可能会收到更多。IMHO-过度缓和。我认为在你真正看到有价值的答案即将到来之后，关闭这个话题并不好。