This forum posting on the SwingX forum has caught my eye:

Having recently switched my main development box to Linux, I have noticed that swingx Linux support is pretty sparse. […] I have had a little dig, and the main culprit seems to be the LookAndFeelsAddons class, more specifically the getSystemAddonClassName() method which only seems to recognize the OSX and Windows OSs – everything else will be defaulted to a ‘Windows Classic Look and Feel’ ! As a result of this, my JXTaskPanes have no visual shading in either the title panel or the main panel. The weird thing is that JXTitledPane actually looks OK (it uses the correct colours for the title bar gradient).

And here is what Richard Bair (the lead of SwingX project) had to say:

The answer may not be very simple either. Since GTK is skinnable, we have to decide how to go about writing UI delegates for these things. Some things like JXStatusBar may have an equivilent type of component in GTK (not sure) which means we’d want to hook into the GTKLookAndFeel somehow to get the right painting code from the OS. Not sure if there is public API in GTKLookAndFeel to do that. And worse for those components that are more custom, like JXMonthView. How do we know what colors to use? I guess it depends on whether GTKLookAndFeel gives us any hints. Adding support to LookAndFeelAddons for Linux/Solaris is the easy bit. Figuring out what to do about it is quite a bit more complicated.

And this brought me back to think about the whole native-vs-cross platform debate that surges every few months in different Swing forums and blogs (with some taking very extreme stance). In this entry, however, i want to compare the implementation costs of these two approaches (and please don’t start flamewars in the comments on which one is better from the user perspective – this entry is about the implementation and not about the visual result).

First announced more than two years ago, the implementation of two core Swing look-and-feels (Windows and GTK) has moved from emulation to using native APIs. As Chet says on his blog

In Java SE 6, the Swing native look & feel for both Windows and GTK was re-written to use the native platform rendering engine to draw Swing widgets. Instead of our old approach of using the native resources and doing our own rendering, we actually call the native rendering system to draw the widgets for us (on Windows, this is done through the UXTheme API). This means that we are finally able to achieve true native fidelity for these components because, by definition, our components are drawn in the same way that the native components are. Not only did this fix corner cases for our XP look & feel, we also made our native look & feel work successfully on Vista.

Hooray going forward? 100% native fidelity for Swing applications running under XP and Vista? 100% native fidelity for Swing applications running under the next Windows release without any change to JRE? Not really. The devil is, as always, in the little details. So, what are they?

Native APIs change. As Chet mentions, Vista draws some components in different ways, so the code for those is different for XP and Vista. Who knows what will be in the next Windows release? Of course, Microsoft is committed to support the old APIs, but it doesn’t mean that the visual results are the same.

Native animations work on native controls. Since Swing controls are lightweight, they are just a bunch of pixels as far as the OS is concerned. This means that Swing has to emulate the animations for the specific OS. In Windows LAF this is done in the AnimationController class that tries to mimic different transitions on various controls. It also makes some assumptions on the native implementation (it assumes that the animations are linear which may not hold in the next Windows releases).

Native painting works on native controls. As with the previous bullet, this means that Windows LAF implementation must map the control state (rollover, pressed, selected, armed, enabled) to the matching OS control state (the later is passed to the native API that computes the colors that match the state). Vista defines over 50 different control states. The next Windows release may define more.

Texts are painted by the Java rasterizer. Many have complained about the rendering quality of default Windows fonts (Tahoma on XP and Segoe UI on Vista), and Karsten Lentzsch even went as far as this:

As a result of this bug [6449753], I consider using the SWT in high-fidelity Swing design to catch up with ClearType (XP) and ClearType (Vista).

Note that this might get better or worse with replacing the existing font rasterizer with FreeType in JDK 7.0.

Native painting supports only native controls. This actually brings me to the forum posting that i quoted in the beginning. With a lot of development going into comprehensive component suites such as JIDE and SwingX, how would one paint controls that have no direct OS counterparts? While in some cases you can address this by “stitching” together background tiles, what would you do with more complex controls such as Office 2007 ribbon, especially if you want to support all OS themes in Windows and GTK?

Native painting is harder to debug. Once you cross the line between Java and native calls, the debugging becomes more complicated. Now you’re dealing with JNI, native methods, possible leaks of native resources etc. On the other hand, the painting implementation itself is done on the OS level, which in most cases would mean less color-level bugs that you need to worry about (as long as you send the right parameters to the native methods).

Native painting is only painting. Java still needs to emulate the “feel” part of the controls. Since all the event handling is done by Java, it needs to “recreate” the keyboard and mouse user interaction with the component (which is just a bunch of pixels as far as the OS is concerned). When the next OS version adds new behavior (feel), Swing needs to add it explicitly.

As you can see, there are quite a few reasons why there are still bugs in the JDK 6.0 implementation of Windows and GTK LAFs. You also might consider these if your requirement is to have “absolute native fidelity” for your Swing application (whatever that means and once again, please don’t start a flamewar that there is no such thing as a native application since Microsoft breaks their own guidelines all the time). Note that this doesn’t mean that you should ditch Swing and move to SWT (or to native code for that matter). It’s just all those implementation quirks lurking just beneath the surface that might rear their ugly head and bite you at a very inopportune time.

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!