[Chapter 1] Abstract Window Toolkit Overview

For years, programmers have had to go through the hassles of porting software from BSD-based UNIX to System V Release 4-based UNIX, from OpenWindows to Motif, from PC to UNIX to Macintosh (or some combination thereof), and between various other alternatives, too numerous to mention. Getting an application to work was only part of the problem; you also had to port it to all the platforms you supported, which often took more time than the development effort itself. In the UNIX world, standards like POSIX and X made it easier to move applications between different UNIX platforms. But they only solved part of the problem and didn't provide any help with the PC world. Portability became even more important as the Internet grew. The goal was clear: wouldn't it be great if you could just move applications between different operating environments without worrying about the software breaking because of a different operating system, windowing environment, or internal data representation?

In the spring of 1995, Sun Microsystems announced Java, which claimed to solve this dilemma. What started out as a dancing penguin (or Star Trek communicator) named Duke on remote controls for interactive television has become a new paradigm for programming on the Internet. With Java, you can create a program on one platform and deliver the compilation output (byte-codes/class files) to every other supported environment without recompiling or worrying about the local windowing environment, word size, or byte order. The first generation of Java programs consisted mostly of fancy animation applets that ran in a web browser like Netscape Navigator, Internet Explorer, or HotJava. We're beginning to see the next generation now: powerful distributed applications in areas ranging from commerce to medical imaging to network management. All of these applications require extreme portability: Joe's Online Bait Shop doesn't have the time or energy to port its "Online Bait Buyer" program to every platform on the Internet but doesn't want to limit its market to a specific platform. Java neatly solves their problem.

Windowing systems present the biggest challenges for portability. When you move an application from Windows to the Macintosh, you may be able to salvage most of the computational guts, but you'll have to rewrite the window interface code completely. In Java, this part of the portability challenge is addressed by a package called AWT, which stands for Abstract Window Toolkit (although people have come up with many other expansions). AWT provides the magic of maintaining the local look and feel of the user's environment. Because of AWT, the same application program can look appropriate in any environment. For example, if your program uses a pull-down list, that list will look like a Windows list when you run the program under Windows; a Macintosh list when you run the program on a Mac; and a Motif list when you run the program on a UNIX system under Motif. The same code works on all platforms. In addition to providing a common set of user interface components, AWT provides facilities for manipulating images and generating graphics.

This book is a complete programmer's guide and reference to the java.awt package (including java.awt.image, java.awt.event, java.awt.datatransfer, and java.awt.peer). It assumes that you're already familiar with the Java language and class libraries. If you aren't, Exploring Java, by Pat Niemeyer and Josh Peck, provides a general introduction, and other books in the O'Reilly Java series provide detailed references and tutorials on specific topics. This chapter provides a quick overview of AWT: it introduces you to the various GUI elements contained within the java.awt package and gives you pointers to the chapters that provide more specific information about each component. If you're interested in some of the more advanced image manipulation capabilities, head right to Chapter 12, Image Processing. The book ends with a reference section that summarizes what you need to know about every class in AWT.

In using this book, you should be aware that it covers two versions of AWT: 1.0.2 and 1.1. The Java 1.1 JDK ( Java Developer's Kit) occurred in December 1996. This release includes many improvements and additions to AWT and is a major step forward in Java's overall functionality. It would be nice if I could say, "Forget about 1.0.2, it's obsolete--use this book to learn 1.1." However, I can't; at this point, since browsers (Netscape Navigator in particular) still incorporate 1.0.2, and we have no idea when they will incorporate the new release. As of publication, Navigator 4.0 is in beta test and incorporates 1.0.2. Therefore, Java release 1.0.2 will continue to be important, at least for the foreseeable future.

In this summary, we'll point out new features of Java 1.1 as they come up. However, one feature deserves mention and doesn't fit naturally into an overview. Many of the methods of Java 1.0.2 have been renamed in Java 1.1. The old names still work but are "deprecated." The new names adhere strictly to the design patterns discussed in the JavaBeans documentation:[1] all methods that retrieve the value of an object's property begin with "get," all methods that set the value of a property begin with "set," and all methods that test the value of some property begin with "is." For example, the size() method is now called getSize(). The Java 1.1 compiler issues warnings whenever you used a deprecated method name.

1.1 Components

Modern user interfaces are built around the idea of "components": reusable gadgets that implement a specific part of the interface. They don't need much introduction: if you have used a computer since 1985 or so, you're already familiar with buttons, menus, windows, checkboxes, scrollbars, and many other similar items. AWT comes with a repertoire of basic user interface components, along with the machinery for creating your own components (often combinations of the basic components) and for communicating between components and the rest of the program.

The next few sections summarize the components that are part of AWT. If you're new to AWT, you may find it helpful to familiarize yourself with what's available before jumping into the more detailed discussions later in this book.

Static Text

The Label class provides a means to display a single line of text on the screen. That's about it. They provide visual aids to the user: for example, you might use a label to describe an input field. You have control over the size, font, and color of the text. Labels are discussed in Labels. Figure 1.1 displays several labels with different attributes.

Figure 1.1: Multiple Label instances

[Graphic: Figure 1-1]

User Input

Java provides several different ways for a user to provide input to an application. The user can type the information or select it from a preset list of available choices. The choice depends primarily on the desired functionality of the program, the user-base, and the amount of back-end processing that you want to do.

The TextField and TextArea classes

Two components are available for entering keyboard input: TextField for single line input and TextArea for multi-line input. They provide the means to do things from character-level data validation to complex text editing. These are discussed in much more detail in Chapter 8, Input Fields. Figure 1.2 shows a screen that contains various TextField and TextArea components.

Figure 1.2: TextField and TextArea elements

[Graphic: Figure 1-2]

The Checkbox and CheckboxGroup classes

The remaining input-oriented components provide mechanisms for letting the user select from a list of choices. The first such mechanism is Checkbox, which lets you select or deselect an option. The left side of the applet in Figure 1.3 shows a checkbox for a Dialog option. Clicking on the box selects the option and makes the box change appearance. A second click deselects the option.

The CheckboxGroup class is not a component; it provides a means for grouping checkboxes into a mutual exclusion set, often called a set of radio buttons. Selecting any button in the group automatically deselects the other buttons. This behavior is useful for a set of mutually exclusive choices. For example, the right side of the applet in Figure 1.3 shows a set of checkboxes for selecting a font. It makes sense to select only one font at a time, so these checkboxes have been put in a CheckboxGroup.

Figure 1.3: Examples of Checkbox and CheckboxGroup

[Graphic: Figure 1-3]

The appearance of a checkbox varies from platform to platform. On the left, Figure 1.3 shows Windows; the right shows Motif. On most platforms, the appearance also changes when a checkbox is put into a CheckboxGroup.

The Choice class

Checkbox and CheckboxGroup present a problem when the list of choices becomes long. Every element of a CheckboxGroup uses precious screen real estate, which limits the amount of space available for other components. The Choice class was designed to use screen space more efficiently. When a Choice element is displayed on the screen, it takes up the space of a single item in the list, along with some extra space for decorations. This leaves more space for other components. When the user selects a Choice component, it displays the available options next to or below the Choice. Once the user makes a selection, the choices are removed from the screen, and the Choice displays the selection. At any time, only one item in a Choice may be selected, so selecting an item implicitly deselects everything else. Choice explores the details of the Choice class. Figure 1.4 shows examples of open (on the right of the screens) and closed (on the left) Choice items in Windows 95 and Motif.

Figure 1.4: Open and closed Choice items

[Graphic: Figure 1-4]

The List class

Somewhere between Choice and CheckboxGroup in the screen real estate business is a component called List. With a List, the user is still able to select any item. However, the programmer recommends how many items to display on the screen at once. All additional choices are still available, but the user moves an attached scrollbar to access them. Unlike a Choice, a List allows the user to select multiple items. Section 9.2 covers the List component. Figure 1.5 shows List components in different states.

Figure 1.5: List components in different states

[Graphic: Figure 1-5]

Menus

Most modern user interfaces use menus heavily; therefore, it's no surprise that Java supports menus. As you'd expect, Java menus look like the menus in the windowing environment under which the program runs. Currently, menus can only appear within a Frame, although this will probably change in the future. A Menu is a fairly complex object, with lots of moving parts: menu bars, menu items, etc. Java 1.1 adds hot keys to menus, allowing users to navigate a menu interface using keyboard shortcuts. The details of Menu are explored in Chapter 10, Would You Like to Choose from the Menu? Figure 1.6 shows frames with open menus for both Windows and Motif. Since tear-off menus are available on Motif systems, its menus look and act a little differently. Figure 1.6 also includes a tear-off menu. The shortcuts (Ctrl+F8) are newly supported in Java 1.1.

Figure 1.6: Examples of menus

[Graphic: Figure 1-6]

The PopupMenu class

The PopupMenu class is new to Java 1.1. Pop-up menus can be used for context-sensitive, component-level menus. Associated with each Component can be its own pop-up menu. The details of creating and working with the PopupMenu class and the fun time you have catching their events are covered in Chapter 10, Would You Like to Choose from the Menu?, Would You Like to Choose from the Menu? Figure 1.7 shows an example of a pop-up menu.

Figure 1.7: A Pop-up menu

[Graphic: Figure 1-7]

Event Triggers

Java provides two components whose sole purpose is to trigger actions on the screen: Button and Scrollbar. They provide the means for users to signal that they are ready to perform an operation. (Note that all components except labels generate events; I'm singling out buttons and scrollbars because their only purpose is to generate events.)

The Scrollbar class

Most people are familiar with scrollbars. In a word processor or a web browser, when an image or document is too large to fit on the screen, the scrollbar allows the user to move to another area. With Java, the Scrollbar performs similarly. Selecting or moving the scrollbar triggers an event that allows the program to process the scrollbar movement and respond accordingly. The details of the Scrollbar are covered in Scrollbar. Figure 1.8 shows horizontal and vertical scrollbars.

Figure 1.8: Horizontal and vertical scrollbars

[Graphic: Figure 1-8]

Note that a scrollbar is just that. It generates events when the user adjusts it, but the program using the scrollbar is responsible for figuring out what to do with the events, such as displaying a different part of an image or the text, etc. Several of the components we've discussed, like TextArea and List, have built-in scrollbars, saving you the trouble of writing your own code to do the actual scrolling. Java 1.1 has a new container called a ScrollPane that has scrolling built in. By using a scroll pane, you should be able to avoid using scroll bars as a positioning mechanism. An example of ScrollPane appears later in this chapter.

The Button class

A button is little more than a label that you can click on. Selecting a button triggers an event telling the program to go to work. Buttons explores the Button component. Figure 1.9 shows Button examples.

Figure 1.9: Various buttons

[Graphic: Figure 1-9]

The Java Management API includes a fancier button (ImageButton) with pictures rather than labels. For the time being, this is a standard extension of Java and not in the Core API. If you don't want to use these extensions, you'll have to implement an image button yourself.

Expansion

The Canvas class

The Canvas class is just a blank area; it doesn't have any predefined appearance. You can use Canvas for drawing images, building new kinds of components, or creating super-components that are aggregates of other components. For example, you can build a picture button by drawing a picture on a Canvas and detecting mouse click events within the area of the Canvas. Canvas is discussed in Canvas.


Acknowledgments		Peers