为什么很难使Java程序“本机显示”？

大多数Java应用程序看起来与C / C ++应用程序不同。Swing可能被设计为具有独特的外观，但是根据我的阅读，例如SWT试图“看起来很自然”，但没有成功。

我的问题是：

对于Java语言的开发人员来说，为什么要设计出完全复制本机GUI 外观的GUI系统很困难？本机GUI有什么不同？设计不仅仅是看起来像“本机”按钮的按钮吗？还是比这更深入？

设计不仅仅是看起来像“本机”按钮的按钮吗？

好吧-对于按钮。但这可能比您想象的要难。如今，用于表示GUI组件的图形已不像被拉伸的随机位图那样简单（因为它们根本无法很好地缩放）-它们通常是基于矢量的图形，并且在其中编写了许多角落情况（因此，当按钮到达屏幕边缘时，它看起来可能会略有不同。）当然，单击按钮时，您将需要不同的图形。出于版权原因，开发人员通常不能直接使用这些现有图形，因此必须重新创建它们-尽管它们在很大程度上做得很好，但由于那里存在大量图形组件，不可避免地会遗漏一些东西。

我说的是基于Swing的所有上述内容，它当然是轻量级的非本地GUI工具包。您特别提到SWT看起来不是本地的，这有点奇怪，因为SWT 是本地的。这是一个在下面使用JNI来调用本机组件的工具箱-因此，如果那里看起来不正确，那不是因为外观。

在某些系统上，实际上有六种工具箱可以被视为“本机”。其中一些具有相当独特的概念或功能，因此在跨平台工具箱中复制它们很乏味。应用程序的外观不仅取决于“外观”，还取决于布局及其行为方式。一些注意事项：

• 在对话框中，“确定”按钮属于哪一侧-左侧还是右侧？公平地说，让我们为每个系统构建一个单独的对话框。
• 我们如何在屏幕上标记默认按钮？颜色，粗体，按钮是否放大？公平地说，我们将其放在样式表中。
• 在Windows上，“ Ribbon”的概念很原始。如何将其转换为功能区不常见的Mac？公平地说，让我们忘记像素精确的布局，并为每个系统提供不同的工具栏实现。
• 菜单栏是窗口的一部分（Windows，还是KDE），还是位于屏幕顶部（Mac，Unity）？公平地说，让我们为每个系统编写不同的实现，因为我们已经舍弃了像素精确的布局
• 字体如何呈现？尽可能脆，还是光滑且抗锯齿？以及应该使用什么字体？请注意，不同的字体具有不同的度量标准，因此根据字体的不同，呈现为相同宽度的同一段落可能具有不同的行数。
• 窗口的背景是单色，图像还是渐变色？我们也将其放入样式表中。
• 滚动条外观如何？按钮在哪里–如果有的话？它们有多宽？或者仅在指针移至某个区域时才显示出来？
• 我们如何结合其他配色方案？
• 预期什么是可拖动的？上下文菜单在哪里？

当这些问题涉及应用程序的行为或总体布局时，无法通过简单的样式表解决。唯一真正的解决方案是为每个系统重新编写应用程序（从而忽略Java的跨平台优势）。唯一可行的解​​决方案是忘记像素精确的布局，并写入一个通用接口，该接口可对特定于系统的工具包进行抽象。Swing采取的解决方案是模拟各种系统，但失败极多。

然后是跨平台的一致性，即您的应用程序在所有系统上看起来完全一样的想法（通常是游戏选择的，这会增加沉浸感）。在桌面应用程序上，这很烦人并且破坏了用户的期望。

是的，它的确更深入。

仅构建此按钮时，构建看起来像Windows或OS X按钮的按钮很容易。但是按钮必须像原始按钮一样“表现”，这可能并不容易：一个版本中可能有更多空间，而另一个版本中没有，可能颜色更适合Windows版本中的设计，等等。

当您拥有一个完整的GUI时，这会变得更加糟糕：OS X程序与Windows程序呈现的内容不同。这几乎不可能在一个GUI中捕获-您将需要两个GUI，但是很少有应用程序引起如此大的麻烦。取而代之的是，他们的目标是“在大多数系统上看起来都不错”-看起来仍然有些陌生，但实用且易于开发。

创建一个看起来像OSX按钮，Windows按钮或任何其他工具包的按钮并不难。但是，大多数环境的UI准则并不像“这就是按钮的外观”的基础那么简单。从UI元素之间的间距到某些众所周知的动作应在列表中显示的顺序，到菜单系统中“首选项/选项”对话框的确切位置，都有许多细微的差别。对于非常简单的用户界面，可以自动执行最常见的情况，但是即使不是大多数UI任务，许多情况也需要更好的操作。

SWT试图在某种程度上实现自动化，并且再次使其适用于简单的UI任务。但是，还没有一种万能的解决方案，因此，当UI变得更加复杂时，它使用的基本方法就开始瓦解。通常可以使它与艰苦的手动UI工作保持一致，但这并不是大多数程序员能够或不愿意在所有平台上做到的事情。

Swing的方法只是尽可能地避开本机工具箱。它不是本机的，也没有尝试成为的：相反，它尝试创建无论在何处运行都看上去（几乎）相同的东西。它并没有试图（徒劳地）取悦所有人，而是试图取悦自己，尽管它取得了成功，但人们可以质疑结果对更广泛的用户群体有多有效。

在期望您的应用程序在每个系统上看起来都尽可能自然，以及期望您的应用程序在每个系统上以相同的方式工作之间需要权衡。没有“正确”的选择。

此外，即使您选择“自然外观”，您也可能希望保护图形工具包的用户免受基础本机组件和API的“改进”，这可能会意外破坏其应用程序。

这就是为什么某些GUI工具包开发人员倾向于提供自己的组件来模仿本机组件，但提供自己的实现。另一方面，开发功能完善的GUI工具包是一项巨大的工作，并且出于经济考虑，可能会导致一些不足。

请注意，此问题不是Java特有的，但是每家生产平台独立工具包的公司都面临该问题。

这都是由于历史。

Sun希望所有Java软件在所有机器上都可以相同地工作。

为了使软件“出现在本地”，它必须与给定OS上的其他软件相同。

Sun竭尽全力使编写与OS集成的Java软件变得困难，因为与OS的任何集成都会使软件在每个OS上的工作方式有所不同。

如今，除了基于Web服务器的软件之外，几乎没有Java程序员关心其他任何事情。

Sun通过招募所有使用基于Microsoft Java的系统的程序员来杀死台式机上的Java，因此使任何早期选择Java的程序员看起来都很糟糕。

编写桌面软件的任何人都在乎“出现本机”，很久以前就学会了不使用Java，并且在每次使用任何Oracle软件时都会增强其观点。

因此，如今，Java程序员不再需要在桌面软件上“本机显示”。

您认为native实际上是本机应用程序在做自己的事情，而像SWT这样的工具箱则遵循该OS的UI的已发布标准。问题是没有人会遵循这些标准来构建应用程序，因此在启动Java应用程序时会如此。它似乎不是本地的。例如，几乎所有Microsoft项目（Office，Outlook等）都无法使用Windows标准控件直观地进行复制。

随着Microsoft和Apple都向其OS平台添加动态UI功能，情况将变得更加糟糕。允许开发人员以与网站设计创建网站样式相同的方式对应用程序进行外观/样式设置。

Android平台上的Java遵循此路径。使用可换皮肤的样式制作以XML定义的Android的UI元素。

Java从未作为桌面平台非常流行。结果，行业中的这些变化没有传播到桌面运行时。只是没有足够的开发人员愿意花时间来解决此问题。

您还希望哪个操作系统看起来“本机”？

您只是不可能 100％地都是所有人的本地人。

SWT等是尽力而为的方法，当您需要做出一些妥协时，它们看起来就像它们所有人一样。

实际上，这种折衷开始变得越来越难以实现。不是因为操作系统，而是因为输入设备。对于触摸屏，您实际上必须进行不同的设计，因为没有鼠标右键。因此，否则，您需要适应相同的功能。

除非您为每个输入设备指定每个详细方面，否则，永远不会有一个魔术按钮将功能从鼠标右键“直观地”转移到客户（此时，您是所考虑的每个平台的本地用户，但是仍然无法使用） -与您尚未考虑的任何内容相比）。

真的很好的问题。在过去的几年中，我一直想知道这个问题，我认为这背后有一些合法的理由，但实际上没有。

我认为答案很简单，很多答案并未真正解决问题。

如果您的语言允许在屏幕上绘制Piexel，则有可能100％基于它创建一个GUI框架，该框架将模仿Windows窗体控件的外观。

由于Java是跨平台的，因此完全有可能确保基于实际运行的系统类型（Mac / Windows），UI将选择在两个平台上看起来都不同，以匹配运行时平台样式。

如您在XAML中所见，例如，UI可以很容易地以结构化的形式和语言呈现。如果花时间去做，那么选择“本地”行为也是可能的。

因此，有可能创建GUI框架，该框架将允许Java开发人员获得在Mac和Windows上看起来本机的应用程序。

因此，我们来谈谈Swing，这仅仅是一个可以为Java创建的GUI框架的无限无限的GUI框架。它的行为方式是如何编程的，而没有遵循上述过程，因此您会在两个系统上都看起来很奇怪。那就是Swing开发人员的选择，没有人强迫他们这样做并表现出这种行为。