+1 Swing If I had my druthers I would go with QtJambi, but since Nokia dropped development for that it has not been able to keep pace with Qt. So that would be immediately out of sync. Plus the need for platform native compiled code is a minus. Fine for the main three (Linux, Mac, Windows) with precompiled libs, but separate compile for anything else equals ongoing maintenance effort. This defeats the point of having a cross-platform language. Java and Clojure will work (.e.g, on FreeBSD, OpenSolaris, AIX), but the GUI won't unless you make extra C/C++ coding effort?
SWT is a minus due to native code needs, too much XML configuration, and the fact that it does not look nearly as good as some people think when used cross-platform. Looks fine on Windows, the Mac side is getting better now that they are starting to use Cocoa underneath, Linux side is questionable with varying appearance across different window managers. Other OS? This is the same as for QtJambi, extra C/C+ + coding effort needed to be really cross-platform. No reason to go with AWT exclusively. A lot of Swing wraps parts of or needs AWT anyway. You can't really get away from it and will be cutting off a limb, so to speak, if you go with it rather than Swing first. A lot of the misgivings about Swing look and feel across platform boils down to bad GUI development efforts. I have seen this many times. Many developers just do not understand the specific interface needs across different platforms and just leave parameters at the default settings, which only by luck will be near optimal. I have developed a number of Swing applications that look pretty close to native (at least on Linux, Mac, Windows, Solaris) so I can say that it takes some attention to platform specific details to make this happen (and access to multiple OS). That is what it takes to develop a serious professional cross-platform desktop application, no way around it (you would even have to do this if going with QtJambi or SWT). Overall, I would go with Swing. The main reason is that it will already be cross-platform on any Java compliant OS that can run Clojure. I think that is the most important thing if you want a GUI to go along with the language. Nothing additional is needed to complicate matters, besides the GUI layer/framework on top of Clojure. Nonetheless, the best idea would be to ensure you have enough abstraction in your implementation so that other GUI toolkits could be "almost" dropped in place later on. That is, it should not close out other toolkits, but going with what will work now or sooner than later is better. Going with Swing is a way to get something out soon without having to spend additional effort worrying about C/C++ libraries, packaging and so on. Get something to work, then the additional toolkits can come. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
