I need a bit of advice from you developers who deal with cross-platform applications (specifically programs with a 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.
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.
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.
Thanks again! :)
Qt has a broader approval, being mentioned in 17 company stacks & 51 developers stacks; compared to JavaFX, which is listed in 6 company stacks and 18 developer stacks.
Qt is a cross-platform application development framework widely used for developing applications that can run on a wide range of hardware platforms with little to no change in the underlying codebase.
Because the JDK is available for all major desktop platforms (Windows, Mac OS X, and Linux), JavaFX applications compiled to JDK 7 and later also run on all the major desktop platforms. The cross-platform compatibility enables a consistent runtime experience for JavaFX applications developers and users.
JavaFX is an open source, next generation client application platform for desktop, mobile and embedded systems built with Java. It is offered as a cross-platform Java library and it delivers consistent graphical user interfaces across a wide range of operating systems and devices.
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.
--H
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With