跨平台的GUI语言/工具包

时间：2010-03-09 13:55:42

标签： user-interface qt cross-platform desktop wxwidgets

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

  1. 所有三个部署平台的单一代码库，没有大量条件逻辑来处理平台之间的差异。
  2. 在所有三个平台上看起来尽可能接近“原生”。
  3. 可以轻松分发到所有三个平台，从最终用户可以轻松安装并且不会遭受极端膨胀（如this ArsTechnica article.中所述）

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

    我不想使用C ++作为实现语言，但我不确定是否有任何实际的替代方案。我最担心的是使用C ++以外的实现语言是部署问题。正如the Ars Technica article中所讨论的，PyQt在任何实际意义上都不符合“简单部署”的要求，我怀疑Qt的大多数其他语言绑定都会遇到相同的部署问题（至少在Mac OS X上）。 Java（或Scala）与QtJambi？QtRuby？wxPython？

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

8 个答案:

答案 0 :(得分：8)

  1. 这取决于您的需求。但总的来说Qt Framework（使用任何语言）和Java SE（使用任何语言）都要好得多，因为它不仅具有跨操作系统GUI库，而且还具有跨OS网络，线程，... wxWidgets仅限GUI。 / LI>
  2. Qt和wxWidgets都很不错。根据我的经验，Qt更好。摇摆是......嗯，不太好。
  3. 用C ++和Java Swing应用程序编写的Qt和wxWidgets应用程序都不是很难在Windows，Mac和Linux上部署。规则是当您使用“本机”语言编程时，部署很简单。 “本地”语言是指框架本身编写的语言。
    4.   

    PyQt在任何实际意义上都不符合“易于部署”的要求......

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

    所以你可能有两个选择：

    1. C ++ / Qt或C ++ / wxWidgets。
    2. Java / Swing如果是原生外观＆amp;感觉要求不是很严格。

答案 1 :(得分：4)

wxWidgets非常好，并且包含一些非GUI代码（与kemiisto所说的相反）：线程，套接字等。

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

答案 2 :(得分：3)

在我的日常工作中，我一直在使用perl和wxWidgets开发跨平台（Windows / MacOS / Linux）。这个组合很适合用于开发（我是一个perl黑客），我很少需要为每个平台包含专门的代码。有一些perl模块可以帮助解决这个问题（例如File :: HomeDir，它知道各种平台上文档目录的规范位置等）。

对于发布，我完全不依赖于系统perl安装，而是构建一个包含在发行版中的perl安装。这样我就可以完全控制应用程序的运行时环境。我通过innosetup发送一个Windows安装程序包，一个包含.app文件的mac os .dmg文件，用户可以直接拖到他们的/ Applications，而对于linux我构建了debian和redhat包。

答案 3 :(得分：1)

你看过Xojo了吗？它绝对满足您的所有三个要求，并且比C ++更容易学习和使用。

答案 4 :(得分：1)

大约十年前左右，以XML的跨平台风格（如XUL）建模GUI，然后使用XML文件显示布局的平台特定渲染引擎流程，这是时尚。然而，这不再是时尚。今天，在2017年，趋势是在平台上构建您的应用程序，允许您使用HTML，CSS和/或JavaScript编写所有内容，无论您的代码应在何种环境中运行。

第一代＆＃34;这类工具产生的基本上是＆＃34; hybrid＆＃34;应用程序，其中Web应用程序在类似浏览器的情况下运行特定于平台的WebViews。然而，这种技术效率很低。你的应用程序感觉不是很好，而且非常臃肿，而且往往缺乏性能。然而，在不同环境中具有一致的外观相对容易。 Phonegap / Cordova 是最受欢迎的移动环境平台， NW.js 适用于桌面环境。

＆＃34;第二代＆＃34;不同之处在于：他们将所有内容编译为完全＆＃34; native＆＃34;，特定于平台的二进制文件。而不是依赖WebViews，＆＃34; native＆＃34;尽可能使用小部件。这为您的应用提供了更多的本地＆＃34;外观，通常具有较少的膨胀，并且性能更好。但是，您在不同平台之间会有更多差异。例如 NativeScript ， React Native ＆amp; Tabris.js （全部适用于移动环境）。

不幸的是，没有第二代＆＃34;桌面工具还没有。所以，现在，如果你想构建一个跨平台的桌面应用程序，你就会被第一代＆＃34;第一代＆＃34;工具。 NW.js的记录比Electron更长，并且支持Electron中没有的各种功能，但是it also comes with its drawbacks。 AppJS仍然年纪较大，但它并不像其他两个那样成熟 - 并且不那么受欢迎。

无论如何，他们对WebViews的依赖意味着您的应用程序将更像是一个Web应用程序而不是桌面应用程序。并且bloat and performance drawbacks are inevitable with this kind of solution。这意味着您将永远不会获得与您直接在Java或C ++中编写的代码相同的性能，也不会获得与第二代＆＃34;第二代相同的性能。平台，它永远不会感觉平等＃34;本地＆＃34;。但是，它仍然是最好的解决方案，例如。当不同平台上的一致外观更重要或者您有作为Web开发人员的背景时。

如果性能，缺乏膨胀和你的应用程序得到那个＆＃34;本地＆＃34;感觉是重要的标准，你可能要等待一段时间，直到第一代＆＃34;第二代＆＃34;平台出现在桌面上。桌面应用程序的平台遵循与移动应用程序平台相同的进化路径，但实际上它可能以桌面扩展程序的形式出现，这只是时间问题。现有的移动平台。

目前正在寻找的方式，看起来你很快就可以写出本土的＃34;＆＃34;桌面和应用程序的应用程序移动设备与完全相同的代码库。如果React Native已经拥有添加support for Windows 10和support for MacOS的插件，我会亲自使用React Native并为他们的开发团队提供一些时间，直到他们支持我需要支持的所有桌面环境并且桌面扩展为足够成熟的生产环境。

如果你不能等那么久，你就不想打赌将来会发生什么，或者这些标准对于你想要的任何应用都不重要今天要建立，你可能想尝试一下第一代＆＃34;目前可用的平台，看看哪个最适合您。请注意这些缺点！

一如既往，明智地选择......

热门平台

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

  • Meteor（建立在Cordova之上）
  • Ionic（建立在Cordova之上）

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

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

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

答案 5 :(得分：0)

.Net（C＃或VB.Net）就是我要用的（事实上，它 我用于我自己的应用程序）。由于Mono项目，.Net应用程序可以在Mac和Linux以及Windows上运行而无需对代码进行任何修改（除非您调用Windows API函数）。您甚至不必编译程序的不同版本：相同的EXE将在所有平台上运行。

答案 6 :(得分：0)

Java / SWT是一个不错的选择。你可以找到很多关于它的信息here。

答案 7 :(得分：0)

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

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

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

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

相关问题
最新问题