I've been constructing the GUI to my trialware app, and I'm not real sure if Apple's done me a favor or not. There are quite a few little quirks that a user expects on one platform that might not be commonplace on another, and these are the final details a software designer has to conquer that really make the Java mantra of "write once, run anywhere" a bit of a misnomer.

When you use VIm, for instance, you have to learn a whole new way of navigating text. To get to the end of a line in VIm in, um, non-edit mode, you type "$". To get to the beginning of the line, you type "^", of course! To move forward one "page", you type "Ctrl-F". Backwards a page is "Ctrl-B". For the most part the "Home" and "End" keys work as expected, but there are a few extra shortcuts.

Similar things exist for most any text area in Macland. Whether you've got Mozilla, AppleWorks 6, or BBEdit (probably the most popular text editor on the Mac) open, every long-time Mac users knows that "Apple-[cursor right/arrow key]" takes you to the end of a line of text, "Apple-[cursor up]" take you to the first line of your text, and so on for the opposites. Applications that stray from this path, like Microsoft Word 98 on the Macintosh, frustrate Mac users. You don't want your app to follow suit.

If you have a keyboard/monitor switch running into several computers like I do, you'll quickly notice another change from one platform to the next. In Windows, you'll find you typically use "Ctrl-S" to save a document but when you use the Macintosh you'll use "Apple-S". This Control-to-Apple key switch happens for most any command when you switch over, like cut, paste, and undo. Now on Apple keyboards, often the Apple key has moved to match the Control key's location on keyboards designed for PCs, so your muscle memory isn't caught so off guard. When sharing a keyboard, however, the muscle-memory learning curve is a bit more pronounced. Using what is essentially the Windows key as the Control key replacement is a little disorienting at first, and requires your thumb to move in ways it's never moved before.

Now consider using Sun's Swing to build your Java GUI. You'll find the GUI behaves the same crossplatform! Super, right? Well, as you may have guessed, not exactly. There are some keyboard shortcuts that come by default with the cross-platform version of the Swing widgets, like cut and paste. On Windows and Linux the "Ctrl-C" and "Ctrl-V" built-in shortcuts are quite welcome, saving you quite a bit of code. On the Macintosh, however, you've got everything wired wrong! Not only do you have to wire up new shortcuts for cut and paste, you should probably, just to be on the complete up-and-up, unwire the Control key shortcuts so that they don't work on the Mac! Sheesh! What a mess!

But before you get too far into extending JTextArea (or, if you're really clever, JTextComponent), check this: Apple's done all the work for you. By using the "UIManager.getSystemLookAndFeelClassName()" method, Apple will default your Swing implementation to Aqua, Apple's new, fancy-smancy widget toolkit on Mac OS X. "Apple-[cursor down key]" will take you to the bottom of your text, just as you expected, without a single extra line of code. "Apple-V" pastes; "Ctrl-V" does not. Great! All my user interface problems solved with a single line of code! And the app looks groovy too! Right?

This isn't a good thing. Apple didn't go far enough - or, if they aren't going to go farther, they've gone too far in the first place.

Consider the issue of dialogs. The Swing-Aqua dialogs don't follow the "Aqua Human Interface Guidelines" (see above link for doc). Here's one of the slip-up's:

The application icon. Because of the Mac OS X window layering model (described
in "Window Layering" (page 70)), an icon is necessary to make it clear to the
user which application is displaying the alert.

Even though many dialog types are the same between Swing and Aqua, the Aqua-Swing dialogs just look like their typical, Metal counterparts stuck on Aqua frames with a slightly more stylish icon. (Metal is Swing's crossplatform look and feel that does a great job acting the same - and I mean exactly the same - wherever it's run.) This is a pretty obvious and tell-tale sign that your app isn't native, the goal of the System look and feel.

Other issues include that Control shortcuts in menus still come up with their Control masks, for instance. So if your menu said "Control-S" for Save with the Windows or Motif Swing look and feel, it still says "Control-S" in Macland. This also means that a keyboard shortcut of "Ctrl-V" in a menu for a JTextComponent means both Apple-V and Ctrl-V will paste in your app. Another problem: The default font size doesn't scale real well in labels. Now you have to recheck the appearance of any label once you've switched to Aqua to make sure "Enter your password" hasn't become "Enter your pass...". The Menu bar is still displayed as part of the frame, not at the top of the screen like a native Mac app. Not to mention all the considerations for rewrites of you application's manual and help file. Everything's different now, and you'll have to rewrite your manual to match. Do I really want to do things half-Apple's way?

I like what Apple's trying to do, I really do. They'd like to make it easy for me to create a Swing UI in Metal and, with the change of a single line, run it on the Mac the way Mac users expect. Unfortunately they're nowhere close. Though there are ways to fix every problem I've mentioned, they each require you get away from the idea of a 100% Pure Java application (a program which, not surprisingly, Sun has "End of Life'd").

To sum up, and to try and make it sound like I'm not whining about my gift horse's crooked teeth, Java GUIs shouldn't try to look like native applications and Apple's wasting our time trying. The whole "[Native] System Look and Feel" idea just isn't going to cut it. Have you seen the Windows look at feel that comes with Sun's Windows virtual machine? Barely updated if at all since Windows 95, it looks horrible and wouldn't convince anyone that you've got a native Windows app. Could be worse; take a look at [my app, such as it is now, in] the Motif look & feel. As a randmo AIMer said to me, it looks great if you'd prefer to pretend you're stuck living in a timewarp taking you to 1986. (It's supposed to look like Sun's Solaris operating system. Okay, more specifically, it's trying to look like a really old version of what become this. Actually, looking at these "updated Motif" shots, this look & feel might be the most on the money! But, um, I'm going out on a limb and saying nobody's "native" apps look like this on a desktop machine, not even most Linux desktops.)

It's too much trouble to emulate native platforms, and Java shouldn't be scared to be its own platform. Swing should reflect this. Hey, Sun, update Metal. Help it run crossplatform in a way users expect. Forget looking native and forget keeping it simple. Work with Blackdown.org and Apple to get virtual machines that run Metal GUIs in a way local users expect. And help truly bring Java GUIs out of the niche of debugging database applications into the realm of the everyday client application.

Phew, rant. Done.