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

#1 楼

设计看起来像“本机”按钮的按钮不只是一个问题吗？


按钮的种类有点多。但这可能比您想象的要难。如今，用于表示GUI组件的图形已不像被拉伸的随机位图那样简单（因为这些位图根本无法很好地缩放）-它们通常是基于矢量的图形，并在其中编程了很多角落情况（因此，当按钮到达屏幕边缘时，它看起来可能会稍有不同。）当然，单击按钮时您将需要不同的图形。出于版权原因，开发人员通常不能直接使用这些现有图形，因此必须对其进行重新创建-尽管它们在很大程度上做得很好，但由于那里存在大量图形组件，因此不可避免地会遗漏一些东西。这已经不像以前那么严重了-如今，如果我在Swing中设置默认平台的外观，我会发现几乎没有什么奇怪的。

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

#2 楼

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


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

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

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

#3 楼

是的，它的确更深入。

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

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

#4 楼

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

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

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

#5 楼

在期望您的应用程序在每个系统上看起来都尽可能自然，以及期望您的应用程序在每个系统上以相同的方式工作之间需要权衡。没有“正确”的选择。此外，即使您选择“自然外观”，您也可能希望保护图形工具包的用户免受基础本机组件中“​​改进”的影响，并且API可能会意外破坏其应用程序。

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

请注意，此问题并非Java特定，而是每个公司生产平台都面临的问题。独立的工具包。

#6 楼

这完全是出于历史原因。
Sun希望所有Java软件在所有计算机上都可以运行相同的软件。

要使软件“显示为本地”，它必须与其他软件运行相同。

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

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

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

很早以前，任何写“看似本机”的桌面软件的人都学会了不使用Java，并且每次使用任何Oracle软件时，他们的观点都会得到加强。

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

评论

---

“ Sun竭尽全力使编写与操作系统集成的Java软件变得困难，”这是错误的。他们只是简单地付出了很大的努力来简化它。 “ Sun强迫所有使用基于Microsoft Java的Java的系统的程序员杀死了台式机上的Java”，这是错误的，Microsoft与Sun的相互敌视导致Microsoft创建了一个与Sun要求不兼容的AWT库版本，从而声名狼藉。 Sun / MS诉讼。

– jwenting
2014年2月4日在9:09

---

@ jwenting，Sun更关心为微软制造问题，然后更关心选择使用微软基于Java的系统的程序员。因此，我放弃了Jave并继续使用MFC，直到C＃出来。

–伊恩
2014年2月4日在9:31

---

也许在Sun有一些人，但是这种感觉是相互的。如果您是专门为单个平台开发的，则首选使用该平台的本机工具，这与公司政策无关。如果您基于“我讨厌Sun”或“我讨厌微软”来选择工具，这些工具在您的专业态度上反映得很差。我主要使用Java，但同时我也使用了Delphi，C＃，Ruby，C ++，C，Progress，无论是最适合手头的工作。而且通常情况最终会是混合解决方案。

– jwenting
2014年2月4日13:02

---

#7 楼

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

随着Microsoft和Apple都向其中添加动态UI功能，情况将变得更加糟糕。他们的操作系统平台。允许开发人员以与网站设计创建网站样式相同的方式对应用程序进行外观设置/样式设置。用可换皮肤的样式用XML定义用于Android的UI元素。

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

#8 楼

您还想让哪个操作系统看起来“本机”吗？

您不可能100％地都对所有操作系统都是本机。当您需要达成某种妥协时，尽力而为的方法看起来对所有人都是原生的。

实际上，这种妥协变得越来越难以实现；不是因为操作系统，而是因为输入设备。对于触摸屏，您实际上必须进行不同的设计，因为没有鼠标右键。因此，您需要在其他方面适应相同的功能。

永远不会有一个魔术按钮将功能从鼠标右键“直观地”移至客户，而无需为每个输入指定每个详细方面设备（此时，您是您考虑过的每个平台的本地用户，但是对于您尚未考虑的任何平台都是非本地的）。

#9 楼

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

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

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

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

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

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

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