Using AIR to add desktop GUIs

Question

Suppose I develop an application with the logic as a CLI program that can be compiled to various platforms. To add a GUI, I could develop native versions separately for each platform or I could use a cross-platform tool like Tcl/Tk, wxLua, or PyGTK. Some people, like Bruce Eckel and James Ward, promote Flash/Flex on Adobe AIR for this.

I've looked into it, but haven't been able to find clear answers to these basic issues.

Native look and feel The Spark architecture in Flex 4 improves support for skinning to the extent that you can match any L&F, it seems. What resources are available for implementing Windows/GTK+/Cocoa L&F and how much work is it?

Responsiveness I would rank these popular toolkits from most to least snappy: FLTK, FOX, GTK+, Tcl/TK, Swing, Qt. Where does AIR fit in this range?

Stability For a long-running app with extensive user interaction, how are the stability and memory management? I've read that memory leaks have been a significant issue with AIR.

Local system access I think the biggest complaint about AIR 1 was its isolation from the local system. Now, AIR 2 adds communication via stdin/stdout with the NativeProcess class. How well is this working out for implementing the functionality you typically want in a GUI?

Package size Ranging from a minor interface with a few buttons and textboxes up to something like an IDE, how big would an AIR version be, compared to say, something in Tcl/Tk or wxPython?

Hand coding If you don't use Flash Builder, how hard is it, relatively, to create or maintain a nontrivial project?

Answer 1

Native look and feel: It's possible to skin a Flex app to make it look native. And load a different skin depending on the OS. There are already Windows and Mac skins (not sure if they are Flex 4 compatible yet) available on www.scalenine.com. But these skins will never be a 100% match since it's replicating the l&f, not actually using native widgets.

Responsiveness: I'd guess it's probably somewhere between Swing and GTK+. But I don't have benchmarks to back that up - just my personal experience.

Stability: As long as the code is good and objects are being GC'd then things should be fine. AIR 2 fixed some memory leaks that caused the issues you reference.

Local system access: NativeProcess allows you to do pretty much anything. But more complex use cases probably need something like Merapi.

Package size: The entire UI component set in Flex is around 2MB. Then any custom code will add to that number. Usually the bitmap assets are what really bloat SWF files. You can look at Apparat as a way to reduce the size of SWF files.

Hand coding: I hand code all of the time with just the open source Flex SDK, AIR SDK, and vim (my text editor of choice). That's all you really need. But you will lose out on code completion, visual debugging, etc. But there are some other open source tools out there for doing these things.