JavaFX 2.0 and Qt for cross-platform application
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
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.
Reading/writing XML files
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.
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.
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.
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.
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.
I hope it helped, cheers
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:
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
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
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.
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.'
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.
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.
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.
Based on these experiences, here are some insights that might prove helpful in the JavaFX vs Qt debate.
- 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/
--H