We would definitely be interested in using something like this for Project Overtone. (http://project-overtone.org) We have already migrated from directly using Swing with the built-in Java interop, to creating a thin layer of clojure functions to trim out the boiler plate, to now wishing we had something more idiomatic.
Swing without question. People who are complaining about the look haven't explored what you can do with the pluggable look and feel system. For example, try the demo on the substance page, where they have a variety of different themes implemented: https://substance.dev.java.net/ My guess is that using Swing will get the library used by vastly more applications, because it will be available as a quick GUI for little utilities and sample apps, as well as full fledged applications. Nobody is going to deal with the pain of SWT unless they have a serious app to build, and even then deployment is a total pain. And no, it isn't a one time thing. Dealing with cross platform, native code is an ongoing process that continues to be annoying every time any one of the host platforms upgrades the GUI libraries. Just think, how often does one of windows, mac or linux upgrade the libraries? The much more interesting conversation is about the style of library you are envisioning. Although it would require a small dependency, one thing I would think about doing is using the MigLayout engine for all layout functionality, under the hood. It provides you with the capabilities of all the Swing layout engines, but the interface is straight forward and makes it easy to evolve your GUI overtime without having to keep shifting which type of layout classes you are using. Probably the two key aspects of the library design are going to be the way you register for and handle events, and the way you update widget state. Dangling references to widgets is also a typical source of memory leaks, so finding a way to cleanly keep track of widgets and get rid of them once they are not needed is going to be valuable. In Overtone we have been using a simple event system that lets you register for events (namespaced keywords), and emit them easily. This works pretty well, although it isn't the easiest kind of code to debug. How would a functional reactive style library work? On May 27, 5:18 pm, Luke VanderHart <luke.vanderh...@gmail.com> wrote: > My side project is a fairly complex GUI application written in > Clojure. Recently, I've become irritated with using Java interop for > everything. It's not that Clojure doesn't have nice java interop - it > does. It's just that when interacting with a GUI framework, which is a > large part of my app, I have to be back in mutable object-oriented > land, worrying about class hierarchies, mutable state, locks, etc. > Yucky. > > So, with a perhaps dangerous lack of sanity and without any guarantee > of success, I've decided to try my hand at writing an idiomatic > Clojure GUI library. If I have success (which I doubt) I will of > course make it available as open source. > > I intend for it to be mostly declarative, with a nice DSL for defining > GUI elements. Each component will also implement map, and use one of > Clojure's reference types as an interface for inspecting / updating > its state. I may also implement some aspects of Functional Reactive > Programming wherever it's convenient to do so. > > What you all must help me decide is what GUI framework to use as the > underpinnings of it. It's genuinely hard to decide. I have at least > some experience with all of them, so I have no strong preference, but > I'd like to get your input. I did consider trying to make it abstract > enough that you could plug in *any* of them under the hood, but > there's enough differences between the frameworks that that would get > very ugly very fast. > > Possibilities are: > > AWT > Pros: native widgets, bundled with Java, low-level > Cons: few widgets, considered somewhat obselete > > Swing > Pros: bundled with Java, good widget selection > Cons: non-native widgets > > SWT > Pros: native widgets, widely used > Cons: requires platform-specific libs > > QT Jambi > Pros: native widgets, huge widget selection, highly-regarded framework > Cons: requires platform-specific libs, writing custom widgets is > hairy, momentum and support seem to be lagging since Nokia dropped > official support. > > Remember, the actual API won't matter - that will be completely > abstracted away. So try to focus on the framework's look and feel. > Also let me know if I've missed any of the framework's key > characteristics. > > Thanks! > > -Luke -- 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
