I have to choose a platform for our product. I have to decide between The Qt Framework and Adobe's AIR. I am well versed with Qt as I have worked for the last two years. I looked up at the Adobe's site but all the info about flex, flash, ability to coding in HTML/ActionScript is overwhelming and confusing. I cannot understand the following about the Adobe ecosystem.

I have the following questions on Adobe AIR:

  1. What language do I use for coding my application? (not just defining the looks of UI)
    Like in Qt I use C++. Is it Actionscript?

  2. Can we say AIR is only for making UI's for apps.

  3. Where is the doc for the utility classes along with AIR?
    e.g. for Qt

  4. Qt ships with a huge set of premade widgets that one can use. Does Adobe ship with any such widget set and if so where can i see it as in url?

  5. I understand flex SDK is open source. Can I make commerical apps and ship them ? Does flex SDK ship everything (compiler, utility classes/widgets)

  6. How much does AIR cost in terms of licensing?

  7. Is there something in AIR that is equivalent to QGraphicsView of QT?

+3  A: 

Flex is open source, you can download the SDK for free, there are no licensing costs associated with it. (see their FAQ)

They do ship a 'flex builder', which is some custom Eclipse I think, and which costs money, but you can perfectly work without it.

The docs can be found at adobe's livedoc pages. (which to some, is enough reason in itself to dislike Adobe ;))

I do wonder, if you are well versed in QT, why are you considering something else? Which advantages do you expect AIR to give you over QT?

I have some experience with both QT and Flex, but not nearly enough to weight one versus the other. I do know QT/C++ is much, much more mature than Flex/ActionScript.

If you already know QT, I don't think the time spend learning a new framework (and programming language) will gain you enough to be honest...

"I do wonder, if you are well versed in QT, why are you considering something else? Which advantages do you expect AIR to give you over QT?" Is it possible to use just the flex SDK which is OSS and ship a commercial app for free ?.
Ankur Gupta
Ah yes, QT costs money for commercial apps, good point :)
it's not horribly expensive, however they no longer put the actual prices on their public website (
I have to evaluate and send a report on AIR vs Qt to management. :-)
Ankur Gupta
an email to their sales group should clear it up :)plu,s I'm sure they'd rather spend even a couple thousand on Qt rather than lose your time (and any other devs) for several months while you learn a different environment
Now Qt is free for commercial applications. Because since Qt4.5 is released under the terms of LGPL

I'll second @Pieter's comment - if you already know QT, moving to a whole new environment is going to take a LOT longer.

QT has the advantage of being cross-platform, and very mature: there are libraries for Windows, Linux, and Mac OS X. I'm not extremely familiar with AIR beyond knowing it's from Adobe, but the product site seems to indicate that it's for rich internet apps ( If that's true, then QT would be the far better choice if you're developing a desktop application.

AIR is also cross-platform
+3  A: 

I've used QT and Flex (not so much Air itself though) and have found that Flex is faster for getting apps up and running as well as modifying, while QT gives you more control -- particularly in the installer. The Air app installer is pretty awkward, or at least it was when I tried it, though it may have been improved since then.

The big advantage of Air is that much of the code for it can be run in Flash inside web pages. You can't access the local file system etc. from the web for security reasons but just about everything else is portable.

+7  A: 

If you needs to access a lot of native libraries, you'll need to stay within your QT environment. Keep in mind that AIR is single-threaded and is run on the Flash Player (something that was originally designed for frame-based animations.) However, depending on the style of application you're building, AIR might suit you just fine.

Beware that AIR can get confusing because there's a few different developer paths to creating AIR applications: 1) using html/javascript and the AIR SDK, 2) using Flash/Actionscript and 3) using Flex SDK and/or Flex builder. The last one is the most capable as far as coming from traditional desktop development background.

Small apps that are Web 2.0 for hooking into web services are good candidates for AIR applications. Things like the IM client Digsby would be great. My favorite AIR app that I've seen thus far is Basamiq Mockups. Other useful apps are TweetDeck. These are good examples of the types of things that are well-suited to solve with AIR.

You should visit the Adobe Showcase and look at some applications:

Also, if you're looking to just get out of the C++ game, I believe QT has some java bindings now...also I remember some python bindings, but never look at those myself.

As far as QGraphicsView, people have done similar things in Flex. I tried Googling right now but couldn't find them initially, but people have taken things like A large image, and then only displayed a current region in the window. Also, in the next version of Flex, they're acutaly building an official ViewPort component:

Thank you. we are making something for kids say a visual programming language. We need a beautiful GUI. I think it's best to stick to QT and use SVG for look and feel.
Ankur Gupta
+1  A: 

If your looking for some examples of "fun" UIs using Qt and SVG, take a look at the KDEGames [1][2] and KDEEdu [3][4] projects. There's lot's of nice code there that uses QGraphicsView and SVG to created scalable interfaces. Of course note that's it's GPL so be careful what you "borrow" if your app isn't.





+2  A: 

Go spend some time with this AIR application and then ask yourself if Adobe Flex and AIR are worth investing your time in mastering (be prepared to ask yourself why something comparable doesn't exist for the likes of C++/QT):

Tour de Flex

Tour de Flex is a desktop application for exploring Flex capabilities and resources, including the core Flex components, Adobe AIR and data integration, as well as a variety of third-party components, effects, skins, and more.

Some of your questions:

  • Flex can be coded in MXML and ActionScript3. AIR additionally supports HTML/DOM/JavaScript programming as webkit HTML render engine is built into the AIR runtime.
  • MXML is an XML declarative DSL that gets compiled into ActionScript3 imperative code. It is quite good, though, for declaratively coding the graphical forms of the UI (i.e., the views of the MVC pattern).
  • ActionScript3 has a heratige that is founded on JavaScript, but it has been embelished to the point it more resembles Java or C#. It has package namespace, classes and interfaces with inheritance, class member access protection keywords, constructors, static members, and some very nice additions over Java: properties, events, data-binding, and closures.

Flex style programming is also a single-threaded model that relies on asynchronous I/O interactions. This is a simpler model to program than multi-threaded Java Swing or C# .NET Winform apps, yet permits achieving the same net results of program behavior. I elaborate on that here:

Flex Async I/O vs Java and C# Explicit Threading

Indeed, Qt's components are poor compared to Flash. I do not know why that is.
+1  A: 

I made the opposite move. I started working on Adobe stuff and moved to QT. The main reason for doing it was about Adobe framework limitations. When you are using Adobe stuff, you are limited to the tools that they produce, it is hard to introduce external frameworks or libraries, if can not do what you want with Adobe stuff. Usually, the solution to do this is to use sockets, which transforms a supposed "stand-alone" application on a client-server architecture. In addition, if you are using many external stuff it can be hard to manage so many different clients. Using QT you can code in C++ and add any external framework or lib you want. Even though, some times it can not be easy to code it, is doable and with no "strange" system architecture.