跨平台GUI语言/工具包

Question

我正在尝试编写一个跨平台GUI应用程序，将部署到Windows、Mac OS X和Linux。我的要求如下：

1. 所有三个部署平台都使用单一代码库，不需要大量条件逻辑来处理平台之间的差异。
2. 在所有三个平台上看起来尽可能接近“本地”。
3. 易于分发到所有三个平台，即最终用户可以轻松安装，并且不会有极端膨胀（如此ArsTechnica文章所述）。

基于这些要求，我已经缩小了工具包的选择范围，只剩下Qt和wxWidgets，因为我所知道的其他工具包（包括Java的Swing和SWT、Flex、AIR等）都不能满足“本地外观”的要求。在这两个最终竞争者中，Qt似乎提供了更好的支持，使应用程序在我部署的所有三个平台上看起来和感觉像本机应用程序，但我愿意考虑相反的意见。

我不想使用C++作为实现语言，但我不确定是否有任何实际的替代方案。我对使用除C++以外的实现语言最大的担忧是部署问题。如Ars Technica文章所述，PyQt在任何实际意义上都不满足“易于部署”的要求，我怀疑Qt的大多数其他语言绑定也会遇到同样的部署问题（至少在Mac OS X上）。Java（或Scala）与QtJambi？QtRuby？wxPython？

有没有人知道任何语言和工具包的组合，可以满足上述所有三个要求？

- Jason Voegele

Answer 1

1. 这取决于您的需求。但是一般来说，Qt框架（任何语言）和Java SE（任何语言）更好，因为它不仅具有跨操作系统GUI库，还具有跨操作系统网络、线程等功能，而wxWidgets只是GUI。
2. Qt和wxWidgets都很好。在我的经验中，Qt更好。Swing...嗯，不太好。
3. 在Windows、Mac和Linux上部署C++和Java Swing应用程序都不是很难。规则是，在使用“本地”语言编程时，部署是简单的。所谓“本地”语言是指框架本身编写的语言。

从实际意义上讲，PyQt不符合“易于部署”的要求...

Python（以及任何默认实现为解释器的其他语言）应用程序在通常意义下（我指独立可执行文件形式）难以部署。

因此，您可能有两个选择：

1. C++/Qt或C++/wxWidgets。
2. 如果本机外观并不是非常严格的要求，则使用Java/Swing。

- Wildcat

---

感谢您的回答。我担心这就是我猜测的答案。"担心"是因为我真的不想使用C ++。哦，无论如何，至少使用Qt的C ++并不像使用MFC的C ++那样糟糕。 :) - Jason Voegele

wxWidgets拥有跨平台的网络、线程、文件系统和许多其他非GUI类，顺便说一下，它不仅仅是GUI。 - Bryan Petty

Answer 2

wxWidgets相当不错，而且包含了一些非GUI代码(与kemiisto说的相反)：线程、套接字等。

wxWidgets的好处是wxPython在OS X上实际上应该很容易部署。还有其他的wx语言绑定，但wxPython可能是最古老的。

- RyanWilcox

---

这都是相对的！与Qt框架或（尤其是）Java SE相比，wxWidgets只是GUI库。 - Wildcat

如果能够轻松地将可分发的wxPython应用程序部署到我所针对的三个平台上，那对我来说将是一个胜利者。是否可以为Mac OS X创建一个标准的“.app”文件，用户可以通过通常的机制“安装”它？还是他们需要先安装支持库？如果可以创建单个.app捆绑包，那么它是否会像PyQt应用程序一样臃肿？ - Jason Voegele

你应该能够将wxPython框架打包到OS X的.app文件中（即将其打包起来，以便用户无需先安装支持库）。如果失败，您可能需要使用苹果的PackageMaker创建一个安装程序，该程序会安装wxPython和您的应用程序。wxPython也预装在OS X上（但在我的64位机器上只安装了32位版本，所以它给我报错）...而且我确定它是较旧版本的wxPython，因此您可能不想使用它。 - RyanWilcox

Answer 3

在我的日常工作中，我使用perl和wxWidgets开发跨平台应用程序（Windows / MacOS / Linux）。这种组合非常适合我进行开发（我是一名perl黑客），我很少需要为每个平台编写专门的代码。有一些perl模块可以帮助我完成这项工作（例如File :: HomeDir，它知道各个平台上文档目录等规范位置）。

在发布时，我完全不依赖系统perl安装，而是构建一个包含在发布中的perl安装。这样我就可以完全控制应用程序的运行环境。我通过innosetup发布Windows安装程序包，通过包含.app文件的.dmg文件发布Mac OS，用户只需将其拖到/应用程序即可。对于Linux，我构建了Debian和Redhat软件包。

- rdolson

Answer 4

你有没有看过Xojo？它绝对符合你的三个要求，而且比C++更简单易学易用。

- Paul Lefebvre

Answer 5

大约十年前，流行将GUI建模为跨平台的XML格式（如XUL），然后使用特定于平台的渲染引擎处理该XML文件以显示布局。然而，现在已不再流行这样做。如今，在2017年，趋势是在允许您在HTML、CSS和/或JavaScript中编写所有内容的平台上构建应用程序，无论您的代码应该在哪个环境中运行。

这种工具的“第一代”基本上产生了“混合”应用程序，其中Web应用程序在类似浏览器的平台特定WebViews上运行。然而，这种技术效率相对较低。您的应用程序感觉不太“本地”，而且相当臃肿，性能也往往不太好。但是，在不同环境中拥有一致的外观和感觉相对容易。移动环境中最流行的平台是Phonegap / Cordova，桌面环境中最流行的平台是NW.js。

"第二代"与之前不同:它们将所有内容编译为完全的"本地化"、特定于平台的二进制文件。在可能的情况下，使用"本地"小部件，而不是依赖于WebViews。这使得您的应用程序具有更多的"本地"外观和感觉，通常具有更少的臃肿，并且性能更好。但是，在不同的平台之间会有更多的差异。例如，NativeScript、React Native和Tabris.js(都适用于移动环境)。

不幸的是，目前还没有针对桌面的"第二代"工具。所以，如果你想构建跨平台桌面应用程序，你只能使用"第一代"工具。NW.js比Electron有更长的历史记录，并支持Electron中不存在的各种功能，但它也有其缺点。AppJS仍然比较老，但不像其他两个工具那样成熟，也没有那么流行。

无论如何，他们对WebViews的依赖意味着你的应用程序会更像一个Web应用而不是桌面应用。这种解决方案不可避免地会出现膨胀和性能问题。这意味着您永远无法获得与直接使用Java或C++编写的代码相同的性能，也无法获得“第二代”平台所具有的相同性能，并且它永远不会感觉同样“本地”。然而，在某些情况下，它仍然可以是最好的解决方案，例如当在不同平台上具有一致的外观和感觉更为重要时，或者当您拥有Web开发人员的背景时。

如果性能、缺乏膨胀和应用程序获得“本地”感觉是重要的标准，您可能需要等待一段时间，直到第一批适用于桌面的“第二代”平台出现。桌面应用程序的平台将沿着与移动应用程序平台相同的演进路径追随，尽管它实际上可能以现有移动平台的“桌面扩展”的形式出现，但这只是时间问题。

目前看来，很快你就能使用完全相同的代码库为桌面和移动设备编写“本地”应用程序了。由于React Native已经有插件支持Windows 10和支持MacOS，我个人会选择React Native，并给他们的开发团队一些时间，直到他们支持我需要支持的所有桌面环境并且这些桌面扩展已经足够成熟可用于生产环境。

如果你等不了那么长时间，你不想赌未来或者这些标准对于你今天想要构建的任何应用程序来说都不那么重要，那么你可能想尝试一些当前可用的“第一代”平台，看看哪个最适合你。只是要注意缺点！

像往常一样，明智地选择...

---

热门平台

移动环境的第一代平台（iOS和Android）

• Meteor（基于Cordova构建）
• Ionic（基于Cordova构建）

移动环境的第二代平台（iOS和Android）

• NativeScript（AngularJS生态系统）。
• React Native（React生态系统）
• Tabris.js

桌面环境平台（Windows，Linux或MacOS）

• Electron
• NW.js
• AppJS

智能家居和物联网设备平台

• iViewer
• Iridium mobile

- John Slegers

Answer 6

Java可以通过使用SystemLookAndFeel来支持“本地外观”的应用程序。尝试的最快方法是在应用程序启动时调用以下内容。

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

请查看此内容以获取有关Java中可用外观的更多信息。

http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html

- Tansir1

---

作为KDE用户的kemisto，我完全明白你的意思。Swing应用程序在KDE上看起来非常不协调，即使在Gnome下本地外观也只是表面现象。 - Jason Voegele

Answer 7

对于这个问题，我会使用.Net（C#或VB.Net）进行开发（实际上，这就是我自己应用程序所使用的）。由于Mono项目的存在，.Net应用程序可以在Mac和Linux上运行，而无需对代码进行任何修改（除非您正在调用Windows API函数）。您甚至不需要编译程序的不同版本：同一个EXE文件将在所有平台上运行。

- MusiGenesis

---

Mono应用程序的部署/安装是如何工作的？对于Mac OS X的终端用户来说，这是一个繁琐的过程吗（意思是他们需要单独安装Mono，然后再安装我的应用程序），还是我可以创建一个简单的.app文件并分发它？Mono应用程序在Mac OS X上看起来是否本地化？ - Jason Voegele

Mono在OS X上使用GTK外观，非常丑陋。在OS X上的IDE（MonoDevelop）表现糟糕...这已经足够让我对部署没有任何想法了。=） - Wildcat

@Jason：你的用户需要安装Mono（如果他们还没有安装），然后再安装你的应用程序，虽然我认为你可以构建一个安装程序来完成这两个步骤（在Windows中可以，尽管我不会费心去做）。关于外观和感觉，我会支持kemiisto的看法，尽管我认为Mac OS本身看起来很糟糕。我的应用程序几乎100%是自绘的，所以对于按钮、菜单等的外观并不太重要。 - MusiGenesis

我并不惊讶于从.NET（因此我可以假设是Windows）粉丝那里听到Mac OS X外观和感觉的批评。;-) 但请相信我，大多数Mac用户真的很喜欢它，并且对任何其他替代方案都感到非常不舒服。也许100％自绘是另一个选择... - Wildcat

@kemiisto：我并不认为Mac OS是糟糕的——只是被高估了。我完全理解希望应用程序看起来像它们实际上属于您的操作系统的愿望——我在Windows中使用iTunes :)这就是为什么我选择一个看起来好像不属于任何操作系统的界面。 - MusiGenesis

Answer 8

Java/SWT是一个不错的选择。你可以在这里找到很多相关信息。

- Ha.

---

使用Eclipse多年后，我并不觉得SVT能够产生真正本地化的外观和感觉的应用程序。 - Jason Voegele

Eclipse看起来不太本地化，因为它的库包含了外观酷炫的自定义组件。 - Ha.