Our goal is to create an app that opens a window looking reasonably like that shown in Figure 4-1.
In this app, the user enters any text in the text box. If the user then enters a file name in the File Name box and chooses Submit, the program saves the contents of the text box to an ANSI 8-bit character file and terminates. If the user chooses Cancel, no file is created and the contents of the text box are abandoned as the program closes. The user also can specify an existing filename as a parameter when starting the program, in which case the program will open with the contents of that file in the text box.
Screenshot-1. The app window we are trying to create.
AWT's User Interface Problem
Small deviations in the output between different graphical libraries are to be expected. You can't expect any two libraries to generate identical output. This has been something of a problem for AWT.
Perhaps you remember the religious wars that used to rage over the Apple Macintosh interface. Apple had strictly defined the Macintosh interface in every detail. The size and placement of buttons was prescribed. The placement of menu items was hotly debated. Programs that committed the unforgivable sin of changing the size of a dialog box button or moving a menu item were resoundingly punished in the market place by disappointing sales. Similar, although less intense, wars raged over the user interfaces of other operating systems.
This isn't to say that such standards are bad—quite to the contrary. I admit to some confusion and frustration when a Windows-based app's first two menus are not File and Edit and the last menu isn't Help. Standards enable users to quickly acclimate to different user interfaces.
Roughly speaking, there are three windowed user interface standards in use today: Windows, Motif (for UNIX), and Apple Macintosh. All three are similar, but each has its own unique peculiarities. To name one trivial difference, Windows uses a two-button mouse, while Motif requires a three-button mouse and Macintosh advocates claim that there's no need for more than one. Proponents of each interface claim small interface differences to be enhancements, but for the most part they're just differences.
User interface differences pose a problem for AWT. A platform-independent AWT app is exactly that: platform independent. The AWT app shares traits with all three of the standard interfaces. Due to differences in the Java Virtual Machine (VM) that executes the Java byte codes, an AWT app looks slightly different—slightly more Windows-like—on a Windows machine than on a Motif machine. At the same time, an AWT app doesn't conform completely to any one of the three common interfaces.
An AWT app really presents a fourth interface style, different from each of the three major standards and not widely adopted by any of them. For applets that reside in the Internet browser world, this isn't much of a problem; the World Wide Web presents its own set of user interface standards. However, it is a problem for apps. Unless the AWT interface style becomes widely adopted, it's difficult to see how AWT-based apps can compete with existing user interface standards.
NOTE
The ability to handle a single file name argument gives a program limited drag-and-drop capability. As we will see later in the tutorial, when you drag a file to our app under Windows, Windows will automatically run the program and provide the file name as its first argument.
Screenshot-1 shows the interface drawn rather simply using a paint program so as not to demonstrate a preference between the AWT or WFC approach.
The exact color of the buttons, text boxes, and window background isn't critical as long as the controls stand out from the background. Although not shown in Figure 4-1, the app should respond appropriately to the window minimize, maximize, and close buttons. For example, clicking the close button in the upper right corner of the window should have the same effect as choosing Cancel. Comments