用于跨平台应用程序的 JavaFX 2.0 和 Qt答案

【问题标题】：JavaFX 2.0 and Qt for cross-platform application用于跨平台应用程序的 JavaFX 2.0 和 Qt
【发布时间】：2012-09-26 03:55:37
【问题描述】：

我需要一些处理跨平台应用程序（特别是带有 GUI 的程序）的开发人员的建议。

我将很快创建一个需要跨平台的应用程序，因此我对两个不同的框架进行了一些初步研究：JavaFX 2.0 和 Qt。

老实说，两者都可以满足我的需求。所以然后我问自己为什么我会选择一个而不是另一个（剧透警报：我不知道答案：P）。我确实知道 JavaFX 2.0 是相当新的（截至 2012 年）并且不完全支持跨平台，但最终会支持。

我提出的问题是：您会将其中哪一个用于跨平台应用程序，您在做出决定时考虑了哪些标准？

感谢您抽出宝贵时间阅读本文！ :)

编辑： 在考虑这个问题时供您参考，我将编写的应用程序涉及读取/写入 XML 文件、显示图像以及创建一些具有自定义功能的小部件。我已经用 .NET 用 C# 编写了一个类似的应用程序，但在考虑 JavaFX 2.0 或 Qt 以实现跨平台可用性时，我希望得到建议。

再次感谢！ :)

【问题讨论】：

Swing，但它归结为您想要实现的目标。跨平台足以下定决心
@MadProgrammer 我同意跨平台的能力足以做出决定。 JavaFX 2 和 Qt 都是跨平台的，而且它们似乎都很容易开发。我在 Java 中使用过 Swing，但只是简单地使用过。你更喜欢 Swing 还是 JavaFX 2 或 Qt？
我更喜欢 Swing，因为它是我所知道的。我也知道有很多非常好的开源 API。因此问题。不知道你希望达到什么目标，很难提出建议。
@MadProgrammer 谢谢！我更新了我的问题，以包含应用程序将包含的活动类型的高级视图。没有一个过于复杂，我已经在 C# 中完成了一个非常相似的应用程序（以及其他几个不相似的应用程序）。这只是我第一次体验到跨平台的需求。
@MadProgrammer 嗯，就个人而言，我不建议将 Swing 用于新项目。我认为 JavaFX 比 Swing 更一致、更易于使用且功能更丰富，并且将来会得到 Oracle 的大力支持。另一方面，Swing 几乎要死了。

标签： java c++ qt cross-platform javafx-2

【解决方案1】：

这是一个老问题：稳定性与前沿。我将尝试根据您的应用程序功能为您提供一些个人见解。

JavaFX 2.0 相当新（截至 2012 年）并且不完全支持跨平台

嗯，Linux、Windows 和 Mac 完全支持它。我可以这么说是因为我正在 Mac 中开发一个 JavaFX 2.2 应用程序，服务器在 Linux 机器上运行，客户端在 Windows 机器上运行。

读/写 XML 文件

我还没有看到比 sax2 更好/更容易/更快的工具/界面来解析 XML。当然，QtXMLPatterns 模块解析器值得尊重，但他们甚至正在开发基于 SAX2 的 XML 解析器（顺便说一句，这并不完整，并且与传统的 SAX1 方法不完全兼容）所以我想说给 JavaFX 2 添加一些分数。

显示图像

这两种技术都可以轻松地显示图像，但 JavaFX 2.2 缺少一些用于图像处理的工具（特别是格式编解码器）。如果图像处理是一个关键问题，我会说 Qt 在战斗中略胜一筹。

创建一些具有自定义功能的小部件。

截至目前，这在 JavaFX 2 中并不是一件容易的事，因为 Stage 对象没有像 ALWAYS_ON_TOP 这样的选项，并且直到 3.0 才会有（2013 年的某个地方）这并非不可能，但 Qt 已经有了一些不错的选择用于自定义/显示/处理小部件的工具，我们根本无法在 JavaFX 中重现。

您会将其中哪一个用于跨平台应用程序，您在做出决定时考虑了哪些标准？

嗯，JavaFX 2.2 是由 Java 构成的，并且是为 Java 编写的。我个人发现用 Java 编程比 C++ 更好也更容易。在 Java 中您永远不必为指针而苦恼，您始终可以依靠垃圾收集器进行内存管理，网络上有大量教程和文档（我相信它们超过了 C++）以及不断增长的 Java 大师社区。

抽象地说，我选择 JavaFX 2.2 是因为它很漂亮，因为它很酷，因为我可以更轻松地处理 MVC 并且因为我喜欢 Java，但我相信如果您的应用程序的小部件部分是它的主要目的。

希望对你有帮助，干杯

【讨论】：

感谢您的详细回答，布鲁诺！我确实认为我想知道两者，但是对于这个即将到来的项目，我认为我将使用 JavaFX 2.2（耶！）。谢谢！

【解决方案2】：

我目前正在研究适合开发离线 html5 创作应用程序的各种跨平台框架。除了跨平台操作（Windows、Linux、OS-X）之外，我的应用还有以下主要需求：

嵌入式数据库嵌入式（或次要的主流浏览器）HTML5 渲染引擎功能强大的可编辑 DND 树、拆分面板和富文本编辑器小部件中型图像处理 U盘便携性

我认真研究了这些框架：

jQuery (JavaScript)、HTML5、CSS3 Google Web Toolkit [GWT]（Java 到 JavaScript） JavaFX 2.0 (Java) QT（C++（Java 绑定可用）） Xulrunner（XML、JavaScript） GTK+ (C) 土坯空气睡衣

我在所有这些技术的书籍上花了一笔小钱，并且我已经开始编写原型代码，看看每个框架能带我多快和多远。

最初，JavaFX 2.0 让我跑得最快，而且幅度很大。对此的简单解释是，使用 JavaFX，所有工具、IDE、库、文档、代码示例、周转、调试、社区支持、制造商 (Oracle) 支持和学习曲线都以最少的阻抗失配结合在一起。

JavaFX 最大的胜利可能是它易于实现客户端嵌入式数据库 (Derby)。令人惊讶的是，对于所有其他框架，这项任务要困难得多，而且“笨拙”。

不幸的是，当我发现 WebView 小部件不从本地 file:// URL 执行 JavaScript 时，我遇到了一个严重的 JavaFX 绊脚石。 QtWebKit、GTKWebKit、Safari 和 Opera（都基于 WebKit）也表现出相同的 file:// JavaScript 阻止行为（但 Chrome 没有），所以我推测这是默认的 WebKit 安全措施。

当时，我认为 file:// JavaScript 问题是 JavaFX 的一大难题，因此我继续开发 jQuery、GWT 和 Xulrunner 原型。然而，结果是，我的原型制作效率大幅下降。与这些其他框架的科学怪人和阻抗不匹配明显比 JavaFX 更糟糕。

如此之多，以至于在杂草中徘徊了数周之后，我回到了我的 JavaFX 原型，非常有动力去寻找解决方法。我最终通过在原型中嵌入 Java SE 6 的 Web 服务器并通过使用以下格式的 URL 加载 JavaFX WebEngine 来连接到本地文件解决了这个问题：“http://localhost:58357/xxxxx.html”解除阻塞 JavaFX 原型这种方式就像回家一样。这是一股真正的新鲜空气，更不用说大大提高生产力了。

基于这些经验，这里有一些见解可能有助于 JavaFX 与 Qt 的辩论。

我同意 JavaFX 与 Qt 的问题，因为这两个框架分别最终成为我的 #1 和 #2 最受欢迎、最有成效的选择。
也就是说，我会将 jQuery/HTML5/CSS3 框架添加到组合中。这框架是如此强大，并且充满了 x 平台的潜力
应用程序开发，我什至可以说它是不可避免。在我广泛搜索小部件控件时，可编辑的 DND 树、拆分器面板和丰富的主要候选者文本所见即所得编辑器小部件原来是开源 jQuery 插件。一旦你解决了本地 file:// 问题， jQuery/HTML5/CSS3 与 JavaFX WebView 很好地兼容小部件。 jQuery/HTML5/CSS3 不足的一个领域是客户端数据库存储。这是JavaFX的组合 jQuery/HTML5/CSS3 框架被证明是非常强大的。
即使它们是用 C++ 编写的，Qt 模块也有 Java 和 JavaScript 语言包装器意味着开发人员不需要知道或使用 C++ 以便使用 Qt。
这表明它不一定是 JavaFX 与 Qt，非此即彼的问题。事实上，一个更有建设性和有益的问题很可能是“JavaFX 和 Qt？”
这带来了另一个重要的观点：我很快发现我的最好的跨平台应用程序开发框架实际上是一个 JavaFX 2、直接 Java SE、Swing 的混合体（用于传统的自定义小部件）、WebKit 和 jQuery/HTML5/CSS3。在路上，GWT，相关的第三方 GWT 库和 Qt 模块可以有可能加入这个组合。这里的重点是使用单个的计划，纯基因框架很快就被淘汰了。
目前，绑定整个混合系统的一个共同线程框架一起是普通的 Java SE。而且因为 JavaFX 2 是基于 Java SE，我的投票是从 JavaFX 2 开始，然后添加 Swing，按需提供 WebKit、jQuery/HTML5/CSS3、GWT 和 Qt。
最后，这篇文章说服了我加入 JavaFX 的行列。 http://fxexperience.com/2012/04/interview-with-peter-zhelezniakov/

--H

【讨论】：

哇，谢谢！您帮助巩固了我在这个项目中使用 JavaFX 的决定。也许你是对的，它不一定要被视为一个或另一个。也感谢您的链接！
很高兴能为您提供帮助。刚刚找到了一种更优雅的方式来加载本地 .html 文件：使用 getResource() 方法将文件名转换为 Java URL 对象。将 url.toExternalForm() 加载到 JavaFX WebEngine 中，瞧。从“JavaFX 2.0 Introduction by Example”一书中得到了这个提示，我认为你会发现它是一项极好的投资。我对 JavaFX 2 的研究越深入，我就越确信它是 RIA 炸弹。
哎呀。脸红。只需在文件名前添加“file:/”（注意单个正斜杠），然后调用 WebEngine.load(file:/xxxxx.html)（相对于 WebEngine.loadContent()），JavaScript 在 WebView 中效果很好。
我也刚刚发现“file:/”是必要的。我真的有点困惑。很高兴您也发现了这一点！
我想知道这个描述是否已经过时。我的 JavaFx 运行外部 js 文件没有问题。

【解决方案3】：

从时间戳中可以看出，4 个月前我报告说我选择 JavaFX2 而不是 QT 来进行原型研究项目。大约 2 个月前，我开始从 JavaFX2 切换到 QT，从那以后就再也没有回头。争论的焦点是从原型设计到生产的转变。在编写生产代码方面，QT 被证明领先于 JavaFX2。

与往常一样，魔鬼在细节中，而正是一堆小东西带来了很大的不同。使用 JavaFX2，我经常面对和解决一些小问题，例如无法控制的拆分器窗格调整大小行为、有限的树控制和有限的 WebKit API 访问（例如，尝试实现浏览器缩放按钮，或将整个网页保存到本地 html 文件 - 可行但比应有的笨重 100 倍）。当这些“次要”变通方法加在一起时，会减慢进度。

有了 QT，这样的障碍就少了很多，因此，从原型到产品的转换是自然的、无缝的，而且速度要快几个数量级。

不利的一面是，使用 QT 进入“Hello World”需要更长的时间。但是，一旦到达那里，生产力就迅速超过并远远超过了 JavaFX2。原因之一是 QT 文档、示例程序和开发人员社区更加广泛。 QT 自 1992 年问世，JavaFX2 自 2011 年问世，这种年龄差异对两个 GUI 框架的成熟度水平产生了显着影响。

至于 Java 与 C++ 的问题，根本不是问题。两者都是很棒的语言。就个人而言，出于各种效率、生产力和性能原因，我发现 C++ 是卓越的 GUI 语言，但同样，这是个人结论。

【讨论】：

【解决方案4】：

我认为 Qt 最好和最有趣的部分是它的信号槽，尤其是在处理线程时，它变得非常容易。

【讨论】：

【解决方案5】：

来自 .NET/C#，您还应该考虑将Real Studio 作为创建跨平台应用程序的一种方式。它肯定满足您对尝试创建的内容的要求，并且比 JavaFX 或 Qt 简单得多。

【讨论】：

谢谢！在做出最终决定之前，我一定会调查 Real Studio。