I'm afraid the day job and a couple of "hobbies" have kept me from updating The Digest Handler to the point I'd feel comfortable marketing it (one needed feature and two annoying bugs that don't kill functionality, but do make it less useful), but that hasn't stopped Sun from making the app work better with its newer JVMs.

Swing's native look on WindowsXP for Java 1.4+ is really quite good now. Here's a quick snap of The Digest Handler (on the left) next to Thunderbird (right) on WinXP:



Even in the rough jpg, you can tell the tabs, font, and shading all look very native in Swing now -- the highlight color's even the same! Apple's had the Aqua look and feel for a while now on OS X (see tiny pic, right), which also does a very nice job of making apps look native. I've also seen a screengrab of an early version of The Digest Handler running on Linux (Gnome, iirc) that looked fairly nice. I think I'll finally move the default look and feel for DH from Metal (the "Java look" or "Cross platform" look) to native. I'm betting most end users prefer apps that look and behave natively (login and password for the previous link are both "archives").

That said, look at the WinXP screenshot, above, again. See how the highlight color is the same in both apps (dark blue) but the text doesn't go from black to white in the Java app as it does in the app using native widgets on the right, making the text difficult to read. It's little gotchas like this that I'll end up programming around that drive me mad. The Java progress bar, otoh, actually does change color of text as the bar grows through it, which is a strange, "We got the system test right here, but not there," situation I don't admire. Kinda like when the makers of Crystal Reports fix an error and then reintroduce the same error in a later version. I understand a programmer -- or a different programmer -- might reintroduce a bug, but you'd danged well better have a test that looks for that bug on the QA department's books now. That's a huge QA gaffe. Not quite so bad here (not a regression of sorts, just differing levels of quality in different widgets), but it's along the same lines.

I'd point you to Joel's article (there's that bear again) on craftsmanship and relate it to this Swing example, but after taking a look at CityDesk, I'm finding it harder and harder to give his anecdotes the stock he believes they deserve. Believe me, he's got better places in the app to put his time than fixing a bug that he says will give him, "ten times as much code to handle large files gracefully, code that maybe 1% of our users will ever see." That's a great thing to fix eventually, but it looks like the way Fog Creek Software is prioritizing issues isn't the most efficient. Scratching the wrong itch doesn't just happen in open source software.