Brett stands corrected (he saw Anthony's reply to his entry, which rightly pointed out that spaces is not SWT but pure-Java-Swing, something that my reply didn't do), he says:
It is a Swing app?!? Colour me dazed. Wow. I need to get out more. Well, between the look of spaces, and the obvious malleability of Swing in IntelliJ, it may be time for me to hack some Swing. (Something else for the resume, and all that.)
This made me think (again) about the 'Java Stigma', i.e., the idea that Java is not good for client apps, that even if you build a client app with Java it will not only (and despite being physically impossible, as Bart Simpson would say) suck but it would also blow, that it would require ridiculously complex installation, that its UI would look so bad it'd seem it had been built for a consortium of martian amoebas rather than for humans.
Nonsense, of course.
So, I thought I'd start to write down some of my ideas in the subject. Hopefully it will not end up being totally incoherent rambling. So here goes:
There are many good Java apps today that demonstrate that Java/Swing is powerful enough to create an application that looks and feels like a native app.
So why was this misperception created and, more importantly, perpetuated?
Well, for one, even though many Java apps have been really cool, historically not a lot of attention has been given to the UI. This was, in big part, because Java wasn't mature enough until JDK 1.2. AWT was clearly inadequate to build a full-fledged app, requiring the developers to build a lot of custom components (remember Wordperfect for Java?).
This started to change about 4 years ago with the final release of Swing included in JDK 1.2. Swing really was useful, but it had a learning curve. Now we're past the learning curve, and still Java apps don't "look native" and many times they look downright ugly, or they look like toys. Why?
One reason: in most cases the UI is designed and implemented after the application is written. This is a mistake. (I will come back to this in a later entry... this diatribe is getting long enough as it is)
Another reason: Layout.
In the "native" world absolute positioning rules. Components are set on grids, with specific locations on the window. Not bad for a native application, but not such a good solution when you need to make the application portable and widgets might end up in different locations, with different sizes, fonts, etc, etc.
Java's solution for this is the concept of LayoutManagers. But LayoutManagers were difficult to use properly until BoxLayout came along. (BoxLayout's algorithm has many similarities to that of TeX). Before BoxLayout, your only choice to do complex layouts was to use (gasp!) GridBagLayout.
BoxLayout is an good, but there are still some rough edges in the way it interacts with the components, specially the apparently strange behaviors one can get sometimes with different minimumSize, preferredSize and maximumSize settings.
Another things I learned when writing spaces: Borders are good. We really don't see it but borders are what make an application pleasant to the eye. You don't even need fancy borders, just mostly EmptyBorders and an EtchedBorder here and there will do. And BorderFactory is a really simple way to reuse all those pesky border objects.
So, conclusions for today:
- The UI should be coded with the program, not after it.
- BoxLayout, Border and BorderFactory are our friends.
[Abort, Retry, Fail?]
