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

JavaFX 2.0 and Qt for cross-platform application

提问by FooBar

I need a bit of advice from you developers who deal with cross-platform applications (specifically programs with a GUI).

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

I will be creating an application soon that needs to be cross-platform and so I have done some preliminary research on two different frameworks: JavaFX 2.0 and Qt.

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

Honestly, both would more than suit my needs. So then I asked myself why I would choose one over the other (SPOILER ALERT: I don't know the answer :P ). I do know that JavaFX 2.0 is rather new (as of 2012) and is not fully supported across platforms, but it will be eventually.

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

The question I pose is this: which one of these would you use for a cross-platform application, and what criteria did you look at when making that decision?

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

Thank you for taking the time to read this! :)

感谢您抽出时间来阅读！:)

EDIT:For your reference when considering this question, the application I will be writing involves reading/writing XML files, displaying images, and creating some small widgets with custom functionality. I've written a similar application in C# with .NET, but would like advice when considering JavaFX 2.0 or Qt for cross-platform usability.

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

Thanks again! :)

再次感谢！:)

回答by Bruno Vieira

It's the old question: stability vs bleeding edge. I'll try to give you some personal insights based on your application features.

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

JavaFX 2.0 is rather new (as of 2012) and is not fully supported across platforms

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

Well, it's fully supported on Linux, Windows and Mac. I can say that because I'm developing a JavaFX 2.2 application in Mac which the server runs on a Linux box and the clients on Windows boxes.

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

Reading/writing XML files

读取/写入 XML 文件

I'm yet to see some tool/interface better/easier/faster than sax2 to parse XML. Of course QtXMLPatterns module parser deservers respect but they are even developing a SAX2 based XML parser (Which by the way is not complete and not fully compatible with legacy SAX1 methods) so I would say that add JavaFX 2 some score.

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

Displaying images

显示图像

Both technologies can display images with enough ease, but JavaFX 2.2 lacks some tools for image manipulation(Specially format codecs). If image processing is a critical matter, I would say that Qt is slight up ahead in the fight.

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

creating some small widgets with custom functionality.

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

As of now, this is not an easy task in JavaFX 2 since the Stage object does not have an option like ALWAYS_ON_TOP and won't have until 3.0 (Somewhere in 2013) It's not impossible tough, but Qt already has some nice tools for customize/display/handle widgets that we simply can not reproduce in JavaFX.

到目前为止，这在 JavaFX 2 中并不是一件容易的事，因为 Stage 对象没有像 ALWAYS_ON_TOP 这样的选项，并且直到 3.0（2013 年的某个地方）才会有这不是不可能的，但是 Qt 已经有一些很好的自定义工具/display/handle 我们根本无法在 JavaFX 中重现的小部件。

which one of these would you use for a cross-platform application, and what criteria did you look at when making that decision?

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

Well, JavaFX 2.2 is made of and for Java. I personally find to program in Java a lot better and easy than C++. You'll never have to struggle with pointers in java, you can always rely on the Garbage Collector for memory management, there are a plenty of tutorials and documentation across the web (which I believe surpasses C++) and an always growing Java Gurus community.

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

In abstract, I've choose JavaFX 2.2 because it's pretty, because it's cool, because I can handle the MVC more easily and because I love Java, but I believe you should go for Qt if the widget part of your application is the main purpose of it.

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

I hope it helped, cheers

我希望它有帮助，干杯

回答by hataman

I'm currently researching various cross-platform frameworks suitable for developing an offline html5 authoring application. Beyond cross-platform operation (Windows, Linux, OS-X), my app also has these major requirements:

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

Embedded database Embedded (or, secondarily, a mainstream browser) HTML5 rendering engine High-functioning editable DND tree, splitter panel, and rich text editor widgets Medium-duty image processing USB stick portability

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

I've taken a serious look at these frameworks:

我认真研究了这些框架：

jQuery (JavaScript), HTML5, CSS3 Google Web Toolkit [GWT] (Java to JavaScript) JavaFX 2.0 (Java) QT (C++ (Java binding available)) Xulrunner (XML, JavaScript) GTK+ (C) Adobe Air Pyjamas

jQuery (JavaScript), HTML5, CSS3 Google Web Toolkit [GWT] (Java to JavaScript) JavaFX 2.0 (Java) QT (C++ (Java 绑定可用)) Xulrunner (XML, JavaScript) GTK+ (C) Adob​​e Air Pajamas

I've spent a minor fortune on books for all these technologies, and I've begun coding prototypes to see how fast and how far each framework could take me.

我在所有这些技术的书籍上花了一笔不小的财富，我已经开始编写原型代码，看看每个框架可以带我走多快和多远。

Initially, JavaFX 2.0 took me furthest the fastest, by a big margin. The simple explanation for this is, with JavaFX, all the tools, IDEs, libraries, documentation, code examples, turnarounds, debugging, community support, manufacturer (Oracle) support, and learning curves came together with the least amount of impedance mismatching.

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

Probably JavaFX's biggest win was it's ease of implementing a client-side embedded database (Derby). With all the other frameworks, this task was, surprisingly, considerably more difficult and 'kludgy.'

JavaFX 最大的优势可能是它易于实现客户端嵌入式数据库 (Derby)。对于所有其他框架，这项任务令人惊讶地更加困难和“笨拙”。

Unfortunately, I ran into a serious JavaFX stumbling block when I discovered the WebView widget does not execute JavaScript from local file:// URLs. QtWebKit, GTKWebKit, Safari, and Opera (all WebKit based) also exhibit the same file:// JavaScript blocking behavior (however Chrome does not), so I surmise this is a default WebKit security measure.

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

At the time, I considered the file:// JavaScript problem a JavaFX showstopper so I moved on to developing jQuery, GWT, and Xulrunner prototypes. As a result, though, my prototyping productivity took a huge nosedive. The Frankensteining and impedance mismatching with these other frameworks was noticeably worse than with JavaFX.

当时，我认为 file:// JavaScript 问题是 JavaFX 的一个障碍，所以我继续开发 jQuery、GWT 和 Xulrunner 原型。然而，结果是，我的原型制作效率急剧下降。与这些其他框架的 Frankensteining 和阻抗不匹配明显比 JavaFX 更糟糕。

So much so that after many weeks wandering around in the weeds, I returned to my JavaFX prototype highly motivated to find a work around. I eventually solved the problem by embedding Java SE 6's web server in the prototype, and connecting to local files by loading the JavaFX WebEngine with URLs in the following format: "http://localhost:58357/xxxxx.html" Unblocking the JavaFX prototype in this manner was like coming home. It was a real breath of fresh air, not to mention big, big productivity booster.

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

Based on these experiences, here are some insights that might prove helpful in the JavaFX vs Qt debate.

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

• I concur with the question of JavaFX vs Qt as those two frameworks respectively ended up being my #1 and #2 favorite, most productive choices.
• That said, I'd add the jQuery/HTML5/CSS3 framework into the mix. This framework is so strong and so loaded with potential for x-platform
  application development that I'd go so far as to say it's inescapable. In my wide-ranging search for widget controls, the leading candidates for editable DND tree, splitter panel, and rich text wysiwyg editor widgets turned out to be open source jQuery plugins. Once you get around the local file:// issue, jQuery/HTML5/CSS3 is nicely compatible with the JavaFX WebView widget. The one area where jQuery/HTML5/CSS3 falls short is with client-side database storage. This is where a combination of JavaFX and jQuery/HTML5/CSS3 frameworks is proving to be extremely powerful.
• Even though they're written in C++, Qt modules have Java and JavaScript language wrappers meaning developers don't need to know or use C++ in order to use Qt.
• This brings up the point that it doesn't have to be a JavaFX vs Qt, either-or question. In fact, a more constructive and rewarding question could well be, "JavaFX AND Qt?"
• This brings up another important point: I'm quickly discovering my best cross-platform application development framework is actually an amalgam of JavaFX 2, straight-up Java SE, Swing (for a legacy custom widget), WebKit, and jQuery/HTML5/CSS3. Down the road, GWT, associated third-party GWT libraries, and Qt modules could potentially join the mix. The point here is the plan to use a single, genetically pure framework quickly went out the window.
• Currently, the one common thread that binds this entire hybrid framework together is plain-old Java SE. And because JavaFX 2 is built on Java SE, my vote is to start with JavaFX 2, then add Swing, WebKit, jQuery/HTML5/CSS3, GWT, and Qt on an as-needed basis.
• Finally, this article helped convince me to jump on the JavaFX wagon. http://fxexperience.com/2012/04/interview-with-peter-zhelezniakov/

• 我同意 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

- H

回答by hataman

I see from the timestamps it was 4-months ago when I reported I had chosen JavaFX2 over QT for my prototyping research project. About 2-months ago I began switching from JavaFX2 to QT, and haven't looked back since. The main point of contention was transitioning from prototyping to production. For writing production code, QT proved to be miles ahead of JavaFX2.

我从时间戳中看到它是 4 个月前，当时我报告说我选择 JavaFX2 而不是 QT 作为我的原型研究项目。大约 2 个月前，我开始从 JavaFX2 切换到 QT，此后一直没有回头。争论的主要焦点是从原型设计过渡到生产。在编写生产代码方面，QT 被证明远远领先于 JavaFX2。

As always, the devil is in the details, and it was a bunch of little stuff that made a big difference. With JavaFX2, I was constantly confronting and working around little things like uncontrollable splitter-pane resize behavior, limited tree control, and limited WebKit API access (e.g. try implementing browser zoom buttons, or saving an entire web page to a local html file - doable but 100X clunkier than it should be). When added together, these "minor" work-arounds slowed progress to a halt.

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

With QT, such roadblocks are much less present, and as a result, transitioning from prototype to product has been natural, seamless, and orders of magnitude faster.

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

On the downside, getting to "Hello World" with QT took much longer. Once there, though, productivity quickly overtook and far surpassed JavaFX2. One reason for this is QT documentation, example programs, and developer community are much more extensive. QT has been around since 1992, JavaFX2 since 2011, and this age difference makes a significant difference in the maturity levels of the two GUI frameworks.

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

As for the Java vs C++ question, has not been at all an issue. Both are great languages. Personally, for a variety of efficiency, productivity, and performance reasons, I'm finding C++ to be the superior GUI language, but again, that's a personal conclusion.

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

回答by Bahramdun Adil

I think the best and the most enjoyable part of Qt is its signal-slot, especially while dealing with threads, it makes it very easy.

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

回答by Paul Lefebvre

Coming from .NET/C#, you should also consider Real Studioas a way to create a cross-platform applications. It certainly meets your requirements for what you are trying to create and will be much simpler than JavaFX or Qt.

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