As the original Swing Sightings series has lost much of the energy behind it (apart from a few occasional entries on the JavaDesktop page), i have decided to start a new series that will feature screenshots of applications running under Substance look-and-feel. Obviously, not all Swing applications are running under Substance (yet, plans on world domination are currently under review), but there are still some very nice applications out there that use various Substance skins and settings to add some style and spice to their UIs.
First up is LightZone which is a very nice digital image editor. An interesting thing to note in the screenshot (click to see original size) is that this application has quite a few custom controls, all of which are skinned according to the selected Substance skin:
The next one is LinuxSampler which is a pure software audio sampler. This application uses a few custom controls as well; note how well they blend with the core Swing controls painted by Substance:
The next one is Darkstar FX that lets you prototype Java 2D renderers in Javascript. The application suite that contains this tool also bundles the Titanium look and feel that is based on one of the core Substance skins.
The last one is Ixent which provides a framework for non-photorealistic rendering.
Note that all the applications in this entry have decided to use the graphite-based skins which have been modeled after Microsoft’s Expression Blend, Apple’s Aperture and Adobe’s LightRoom.
If you haven’t tried Substance in your application, you’re more than welcome to do so. The current stable release is 3.3, and the next 4.0 version (code-named Key Largo) will be released on September 3rd (release candidate August 20).
The previous entry featured an interview with Romain Guy, the co-author of the “Filthy Rich Clients” book. Today it’s time for Chet Haase, the second author behind this book.
Why have you decided to write this book?
I’ve wanted to write a book for some time – something in the general area of Java and graphics. Then when the idea came up or Filthy Rich Clients, it all made sense. Maybe all I needed as a catchy title?
This is your first book. Looking back, is it easier or harder than what you thought it would be?
Hmmm – mixed.
Actually, the writing itself went better than I thought it would. It turned out that Romain and I could produce lot of content in a relatively short time, and we enjoyed doing it.
But editing the book was quite different; it was sheer hell and torture. Specially painful was the part where people whose opinion you respect review the material and tell you everything that you’ve gotten wrong. It was a dark and depressing winter.
Are you happy with the way the book turned out to be?
Very happy. I think there’s a nice mix of fundamentals, telling people the way things work inside Swing and Java 2D, and very fun stuff, showing how far they can take the platform to create cool applications. There are lots of demos to illustrate the points, lots of pictures to show how things look, and lots of footnotes to help pass the time and fill in all of that empty space at the bottom of the pages.
What is your favorite chapter and why?
Actually, I’ll choose a whole section and not just a chapter:
Part IV: Effects.
All of the material in this section was the original inspiration for the book – let’s show developers how to do the cool stuff for their applications. The rest of the book is all about showing how everything works so that you can understand the Effects section completely when you get there. It’s one thing to just copy & paste some demo code, but it’s much more powerful to be able to understand how it all works so that you can go write your own custom effects.
Jokes on “this is not a book on binding” aside, do you see the business developers adopting the techniques you’re explaining in the book?
Absolutely. I think that any application (perhaps especially some of the truly awful ‘enterprise’ applications that I’ve had to use) could benefit from a better user experience. The effects we discuss in the book are all about enabling better user experience.
For example, the techniques outlined in the Animated Transitions chapter are about creating a seamless flow in an application and avoiding the Submit-Erase-Repopulate UI experience of most web applications today. These techniques could apply just as well to a typical forms-based application as to a more consumer-oriented application.
Using effects is not about animating and jazzing up anything and everything arbitrarily in a user interface; they’re about using the right technique to achieve the goal and improving the experience of the user to make them more productive in using your application. And heck, maybe your users will even like your application more in the process.
Have you thought about adding tooling support (for example in NetBeans) for the TimingFramework?
I would love to see tool support for creating animations in general, whether it’s a tool for creating animated applications or just adding animated effects to a standard GUI.
The original goal of the Timing Framework was not just the library itself, which is just about the plumbing details of running timers and interpolating values, but to help make animations easier in general. I can envision other libraries layered on top of the Timing Framework to make animated effects easier, or component animations easier, or animated transitions easier. And then on top of these, we need tools to make it all dead simple to all developers.
Are you planning on writing more books on desktop technologies in general and on Java desktop in particular?
It’s entirely possible. I’d like to find the intersection of material that the community would like to read and technology that I would like to write about. Specifically, are there other graphics-related topics that warrant a book? Or maybe just one on Java Jokes?
What are your top three wishes for the desktop APIs for the next JDK release?
Animation, performance, and animation.
What are the top three desktop APIs that you wish never existed in the JDK?
Do I have to limit this to desktop APIs?
First on my list is whatever set of classes with ALL_CAPS names. I think the culprit is Corba. I spend a lot of time with the JavaDocs, and I sure am sick of seeing all of those CAPITALIZED classes screaming out at me from the list of all classes.
Next would be PixelGrabber, which tends to be a common way (still!) that people use for getting at the pixel data of an Image. If only we had created BufferedImage in 1.0, then there would have been a far easier and faster mechanism for getting that data.
Finally, I’ll pick on Image.getScaledInstance(). It’s just too horribly slow to be useful, but many people still use it because it’s probably the most obvious route to quality down-scaling in the API. Check out the Images chapter in the book or Chris Campbell‘s excellent article on java.net for the nitty gritty details on how slow this method is and what better alternatives you have.
Do you see yourself in Java desktop area in five years?
Sure! You can never tell about this stuff, but it’s clear that I’ll be fooling around with pixels somewhere. If it’s not related to graphics, I’m probably not interested.
Would you take this book with you to a deserted island?
I think not. After writing, re-writing, and editing the entire book several times, I’ve probably read it enough for several lifetimes. On the other hand, perhaps it would help me pay for passage on a rescue ship. Also, at something like 550 pages, the book would probably help provide some starter fuel for campfires.
Would you take Romain with you to a deserted island?
And then leave him there? That would be cruel, but it’s worth considering.
Besides, Romain loves dessert, so I’m sure he’d love a dessert island.
Does Romain have a good taste in food, or is it just a stereotype on French people?
He eats more American junk food than anyone I know. So either our junk food is of very high quality, or the French palate is highly overrated. Or maybe he’s not French and he’s just been faking that accent this whole time.
With the “Filthy Rich Clients” book just around the corner, the co-author Romain Guy was gracious enough to answer a few questions that i had about the book and the related topics.
Whose idea was it to write the book?
Chet came up with the idea. Chet loves to write and his wordy, yet, rare, blog entries are a good giveaway. That Chet wanted to write a book seemed quite natural to me. Because I also really enjoy writing, I translated a few books for O’Reilly and wrote a couple hundreds articles for technical magazines, Chet offered me to co-author the book. Besides, our skills are very complementary. Chet takes care of the technical groundwork and the jokes while I handle high-level effects and visual stuff. He knows how to write code, I know how to use Photoshop.
How much time did you spend on writing your part?
It’s hard to come up with a precise answer. My writing spanned over about 4 months, during which I was quite busy with school and exams. I spent long periods without writing anything and did most of the work in short but intensive bursts. That’s how I always worked but it drove Chet insane. He was quite worried at times but we delivered in time.
Did you use any special collaboration tools on those chapters that you wrote together?
Unfortunately, no. I have used Subversion and CVS in the past for that kind of work, but we relied entirely on Word’s tracking system, IM (a lot) and email (gazillions of emails were exchanged.) We did not bother much with collaboration tools because we worked separately on chapters. Only chapters 2 and 5 contain text that we both wrote. However, I was worried about losing work when trying to merge the files we exchanged by email. Actually we made a mistake once and almost lost a bit of work; good thing I have two daily external backups. And I know that for our next book we will use plain text and Subversion.
How did you decide on what goes in the book and what stays out?
That’s quite easy. Everything went into the book, nothing stayed out. As I said earlier, Chet and I are quite experienced writers. Besides, we thought hard about the content before starting writing the first pages and it was very clear to use what the final content would be. We did shuffled chapters around but we didn’t have to suffer from any cut or large addition.
How did you handle the inherent restrictions of the printed format for such a dynamic area as animations?
One of our recurrent jokes was to print an animation’s frames in the corner of the pages and use the book as a flip-book. From the beginning we knew that the book would have a companion site with all of the source code. We also simply decomposed a few animations as a series of screenshots or diagrams in the book. While it doesn’t look as good as the real animation, it does an excellent job at showing precisely what happens on screen.
Do you see value in writing books in the blog era?
I definitely do. Even though I spend a lot of time every day reading blogs and online articles, I always find it tedious to read on a screen. Blogs also tend to focus too much on details or, on the contrary, do not delve enough into the details. This is very valuable but a book is always, to me, a better asset when I need to learn about a technology or a topic I know nothing about.
I know that glass panes were your favorite technique once. Has this changed?
I would say that my favorite technique was and still is @Override protected void paintComponent().
What are your top three wishes for the desktop APIs for the next JDK release?
I am pretty happy with the APIs as they stand now. That said, I’d love to see non-rectangular windows, lightweight/heavyweight integration (which would bring video, 3D and 2D together) and something like SwingX‘s painters.
What are the top three desktop APIs that you wish never existed in the JDK?
One is obvious, AWT. Just because I’m tired of explaining on forums that you should not use Canvas and Button but JComponent and JButton. And it has nothing to do with Java, but I have a profound dislike for Tk and wxWidgets APIs.
What other non-Java desktop toolkits do you use? What can Swing learn from them?
I used Tk, wxWidgets and QT quite a lot in the past. I am particularly fond of QT, even though it’s far from perfect. Nowadays, I also enjoy working with Cocoa. The interesting thing about those toolkits is very often the ease of use. Their architecture is not always very pretty but you can get things done with them very quickly and they are easier to apprehend. I don’t think Swing could learn anything from them since it’s too different and too complex now. However, Sun could learn from them for a possible new toolkit; it’s all about ease of use and making common use cases easy to implement. Desktop Java developers could learn from those toolkits. For instance, I am fond of Cocoa developer’s use of images. Instead of tinkering with drawing APIs for hours to create a nice looking widget, they just stitch a few images together. It’s simple and efficient.
Would you take this book with you to a deserted island?
No, I’ve read it so many times that I know it by heart now.
Would you take Chet with you to a deserted island?
Only if I can also bring a typewriter to keep him busy and prevent him from telling me his jokes.
Do you actually like Chet’s jokes?
I actually do like them a lot!
Over the past two weeks i have presented a few solutions to paint validation overlays in Swing. The sheer variety of the solution spectrum serves to highlight the extensibility of the Swing painting pipeline.
As can be seen from even such a simple example as validation overlays, there are many ways to achieve the desired functionality in Swing, each one having its advantages and disadvantages. This variety is, perhaps, Swing’s biggest blessing and biggest curse. On one hand, if you know how Swing works, you can achieve almost everything. On the other hand, if you’re a novice developer, it’s just too much to handle.
In addition, you need to be fully aware of the limitations of each technique to choose the one that best suites your needs. There is no single silver bullet that works best for all requirements, and in most cases the best solution would be a combination of two or even more working together. Hopefully this series has helped you put a few more tools in your developer arsenal. So the next time you need to provide some custom painting functionality, look at the Swing painting pipeline, weigh all the options and go with the one that would work best for your specific requirements.
To sum up, here are the links to all the entries:
- Repaint manager
- Overriding paint() manually
- Using AOP to override paint()
- Custom border
- Layered pane
- Glass pane
- JXLayer
- Extending look and feel
- Multiplex look and feel
