You must read Filthy Rich Clients by Chet Haase and Romain Guy. I really think the subtitle should be the definitive guide to Swing. I’m only about 1/6 of the way through it and already have gotten dozens of ideas. Each chapter has several little examples that each spawn an "A-ha" moment. Chapter 19, my favorite, takes you through the process of designing the UI for Aerith with scans of scribbles and design flows. It makes it very organic and approachable.
Full disclosure: Romain Guy is one of my mentors for the Google Summer of Code and I am also conversant in French. Neither of which should be held against me. The book is available on pre-order from Amazon.com and in electronic format from Safari Rough Cuts. Lol.
I like the concept but am not exactly enamored with the execution. I've been watching the project for a while but I feel the approach is wrong. If you look to any other platform, most notably .NET, there are a small number of ways to do things, many times even just one. It's often been said that Java dies from the ability to choose, splitting market share so much that developer confusion ensues. I'm not suggesting that there be only one option. If a new one is introduced, it should bring significant value. No disrepect to Chris Oliver but I don't believe it does. As noted elsewhere, the syntax is a bit reminiscent of the SwingBuilder. No worries about that, it's not like Groovy has a patent on syntax. :-) My main gripe is that it seemed like the FAQ bashed Groovy for no reason.
"Groovy and other languages have two specific traits which don't precisely meet these needs, namely that they are generic in nature and don't provide the appropriate abstractions necessary to optimize the UI design process and similarly are designed specifically for programmers other than content authors."
Builders can make Swing incredibly simple. One could argue that Groovy builders trump F3 cum JavaFX because they are ingrained into the language and not a DSL on top of Java.
We have had to explain for years that ECMAScript(J*vascript) and Java have nothing to do with each other and was just a marketing ploy. "You're good in Java, right? Do this JavaScript thing for me." F3 was cool, descriptive, very mathematic. JavaFX is blah. For the record, I prefer AB5k over Glossitope as well.
Since I'm coming close to a decently working version with barebones functionality, and a decent amount of chatter on the mailing lists, I've talked it over with MrG(Guillaume) and I will be implementing some of the F3 demos with the Swing(X)Builder. ETA is currently unknown, I wanted to wait a little bit to really familarize myself with it and not be one of the also-blogged* in the aftermath of JavaOne. Expect it in probably a couple weeks.
[Yeah, it's a made-up phrase, or so says Google. In this context, I mean blogging on something after the fact being nothing more than a regurgitation of established facts and/or stints of blatant anti/fanboy-ism without any offering of either new or supporting data.]
My initial though is a resounding no. Before you start typing a comment, hear me out. With most components, layouts, widgets, you can very quickly figure out in your head how they will be implemented. Not so with GroupLayout. GroupLayout is already a mish-mosh of enchained groups. Converting it to Groovy’s builder paradigm would make it look more spaghetti code-esque. Why should it be supported in the first place? IMHO, I think that whatever GroupLayout can do, GridBag can do as well. MIGLayout, of recent press on JavaLobby, looks like it could fill this role as well.
Note: My GSoC project is to create a SwingXBuilder.
I think I read somewhere that every programming language has its weird concept that is confusing at first but makes you feel like a complete noob for not getting it earlier when you finally do. I think that concept for Groovy is the builder. I looked over the pertinent chapters in GINA, rereading, and it wasn't clicking. [It being how to create a builder.] So I started messing around with creating a builder for iText to create a really watered-down PDF builder. It finally clicked but whenever I see a class now, I'm always wondering in the back of my head if it can be optimized by using a builder.
After letting it sink in for a week, I'm pleased to announce that my proposal for the Google Summer of Code, to create a SwingX Builder, was accepted. I will be mentored by Guillaume Laforge. Romain Guy [of Filthy Rich Clients fame] has offered to help with the any questions I might have about SwingX.
The Codehaus was allotted four spots in total. The other three spots went to the Castor project, all centering around adding JAXB2 support.
You can check out the proposal abstracts here: http://code.google.com/soc/codehaus/about.html
Here are the links for the GroovyDesklet binary file and source.
GroovyDesklet.desklet
groovydesklet.groovy
The groovy jar in the maven repo is a barebones version with only the groovy classes so some extra classes are needed. Mavenizing the desklet cuts 2.2MB from the size.
Totally fascinated by AB5k, I ended up working on a Groovy Desklet late into the night. One of the weird spots is that the DeskletContext doesn't obey an explicit
setSize(...)
call. I had to follow the example of the included desklets and use
setPreferredSize(...)
instead.
Another sticking point was the fact that the classes from the groovy embedded jar had to be put into the desklet to run in AB5k. Hopefully in upcoming versions, it will be included in the webstart download.
The desklet doesn't do much at all. It contains a couple labels and a button. One label shows the time the desklet was started or stopped and the other indicates how many times the button was clicked.
Josh Marinacci and Robert Cooper recently released a preview of the Java desklet toolkit, AB5k. A desklet is a Java widget. This is something I've wanted for a while. Despite using a version of my beloved Ubuntu Linux at Google, they never made a timetable for Google Desktop to come to Linux. Now it won't need to. I think this aligns well with Groovy since a desklet can be written in any JVM language. A desklet, a small self-contained component that does a single task well is well suited for the scripty nature of Groovy. Time to port some Apple widgets.
Scott Delop asked on InfoQ if Java needs an answer to Rails. I’ll kinda disregard the Ruby zealots/bashing and simply state yes. Though JRuby can run Rails applications albeit not the latest version, it still requires knowledge of Ruby. Just because JRuby on Rails is maturing doesn’t mean we should throw Groovy/Grails to the waist side. JRuby provides an exit path for disillusioned Rubyists who don’t want to start from square one whereas Grails will be the language of choice from Java folk who haven’t or prefer to not learn Ruby. We can all get along.
