Download Abstract Window Toolkit

Abstract Window Toolkit
From Wikipedia, the free encyclopedia
Windows form with some AWT examples
The Abstract Window Toolkit (AWT) is Java's original platform-independent windowing,graphics,
and user-interface widget toolkit. The AWT is now part of the Java Foundation Classes (JFC) — the
standard API for providing a graphical user interface (GUI) for a Java program. AWT is also the GUI
toolkit for a number of Java ME profiles. For example,Connected Device Configuration profiles require
Java runtimes on mobile telephones to support AWT.
Contents
[hide]

1 History

2 Architecture

3 Mixing AWT and Swing components

4 Implementation

5 See also

6 References

7 External links
[edit]History
When Sun Microsystems first released Java in 1995, AWT widgets provided a thin level of abstraction
over the underlying native user-interface. For example, creating an AWT check box would cause AWT
directly to call the underlying native subroutine that created a check box. However, a check box
on Microsoft Windows is not exactly the same as a check box on Mac OS or on the various types ofUnix.
Some application developers prefer this model because it provides a high degree of fidelity to the
underlying native windowing toolkit and seamless integration with native applications. In other words, a
GUI program written using AWT looks like a native Microsoft Windows application when run on Windows,
but the same program looks like a native Apple Macintosh application when run on a Mac, etc. However,
some application developers dislike this model because they prefer their applications to look exactly the
same on every platform.
In J2SE 1.2, the Swing toolkit largely superseded the AWT's widgets. In addition to providing a richer set
of UI widgets, Swing draws its own widgets (by using Java 2D to call into low-level subroutines in the local
graphics subsystem) instead of relying on the operating system's high-level user interface module. Swing
provides the option of using either a system "look and feel" which uses the native platform's look and feel,
or a cross-platform look and feel (the "Java Look and Feel") that looks the same on all windowing-system.
Abstract Window Toolkit (AWT) is a set of application program interfaces ( API s) used by Java
programmers to create graphical user interface ( GUI ) objects, such as buttons, scroll bars, and windows.
AWT is part of the Java Foundation Classes ( JFC ) from Sun Microsystems, the company that originated
Java. The JFC are a comprehensive set of GUI class libraries that make it easier to develop the user
interface part of an application program.
[edit]Architecture
the AWT provides two levels of APIs:

A general interface between Java and the native system, used for windowing, events, and layout
managers. This API is at the core of Java GUI programming and is also used by Swing and Java 2D.
It contains:


The interface between the native windowing system and the Java application;

The core of the GUI event subsystem;

Several layout managers;

The interface to input devices such as mouse and keyboard; and

A java.awt.datatransfer package for use with the Clipboard and Drag and Drop.
A basic set of GUI widgets such as buttons, text boxes, and menus. It also provides the AWT Native
Interface, which enablesrendering libraries compiled to native code to draw directly to an
AWT Canvas object drawing surface.
AWT also makes some higher level functionality available to applications, such as:

Access to the system tray on supporting systems; and

The ability to launch some desktop applications such as web browsers and email clients from a Java
application.
Neither AWT nor Swing are inherently thread safe. Therefore, code that updates the GUI or processes
events should execute on theEvent dispatching thread. Failure to do so may result in a deadlock or race
condition. To address this problem, a utility class calledSwingWorker allows applications to perform timeconsuming tasks following user-interaction events in the event dispatching thread.
[edit]Mixing
AWT and Swing components
Prior to Java 6 Update 12, mixing Swing components and basic AWT widgets often resulted in undesired
side effects, with AWT widgets appearing on top of the Swing widgets regardless of their defined z-order.
This problem was because the rendering architecture of the two widget toolkits was very different, despite
Swing borrowing heavyweight top containers from AWT.[1]
Starting in Java 6 Update 12, it is possible to mix Swing and AWT widgets without having z-order
problems.[2][3]
[edit]Implementation
As the AWT is a bridge to the underlying native user-interface, its implementation on a new operating
system may involve a lot of work, especially if it involves any of the AWT GUI widgets, because each of
them requires that its native peers be developed from scratch.
A new project, Caciocavallo, has been created, that provides an OpenJDK-based Java API to ease AWT
implementation on new systems.[4][5] The project has successfully implemented AWT widgets
using Java2D.[6] All the necessary core-JDK modifications have since been pushed to OpenJDK
7,[7] which means that Java can now be used on a graphics stack other than one of those provided by the
official JDK (X Window System, OpenGL or DirectX), by including an external library and setting some
system properties. ADirectFB backend for Caciocavallo[8] is under development, as is
an HTML5 backend; the aim is to deploy existing Swing applications—without Java support—as ordinary
web applications running on a web server.[8][9]
[edit]See
also
Java portal
The
Wikibook Java_Swings/AWThas a
page on the topic of:graphic
programming in Java

Standard Widget Toolkit
[edit]References
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November
2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.
1.
^ Fowler, Amy (1994). "Mixing heavy and light components".Sun Microsystems. Retrieved 17 December
2008.
2.
^ Geertjan, Wielenga (16 December 2008). "A Farewell to Heavyweight/Lightweight Conflicts". Retrieved 17
December 2008.
3.
^ "Bug/RFE fixed in current JDK 6u12 build". Sun Microsystems. 12 December 2008. Retrieved 17
December 2008.
4.
^ Torre, Mario (2 March 2008). "FINAL PROPOSAL: Portable GUI backends". Retrieved 7 September
2008.
5.
^ Kennke, Roman (18 December 2008). "Caciocavallo Architecture Overview". Retrieved 7 September
2008.
6.
^ Kennke, Roman (3 September 2008). "Cacio Swing AWT peers". Retrieved 7 September 2008.
7.
^ "How much has been pushed upstream?". openjdk.java.net. 20 September 2009. Retrieved 7 March
2010. "You don't need anymore those patches, with the latest FontManager push, everything is upstream
now, so just use the Cacio repo, it's completely self contained."
8.
^ a b Kennke, Roman (28 July 2011). "JDK7 and Cacio coolness". Retrieved 8 August 2011.
9.
^ Eisserer, Clemens. "HTML5/Canvas backend for Caciocavallo (GNU-Classpath)". Archived from the
original on 10 August 2011. Retrieved 8 August 2011.
Structure of the AWT
The structure of the AWT is rather simple: Components are added to
and then laid out by layoutmanagers in Containers. We have a variety of
event handling, menu, fonts, graphics classes in addition to those two, but
they'll be only briefly discussed here.
Nothing prevents us from using threads, audio, I/O, networking classes
alongside the AWT. The AWT by itself is rather bare and empty. Imagine a
text editor that couldn't save! As a side note, the AWT can be used in a standalone Java application or in an applet that is embedded within a HTML
document.
The AWT hierarchy
Classes:



















BorderLayout
CardLayout
CheckboxGroup
Color
Component
o Button
o Canvas
o Checkbox
o Choice
o Container
 Panel
 Window
 Dialog
 Frame
o Label
o List
o Scrollbar
o TextCompoment
 TextArea
 TextField
Dimension
Event
FileDialog
FlowLayout
Font
FontMetrics
Graphics
GridLayout
GridBagConstraints
GridBagLayout
Image
Insets
MediaTracker
MenuComponent
o MenuBar
o




MenuItem
 CheckboxMenuItem
 Menu
Point
Polygon
Rectangle
Toolkit
Interfaces


LayoutManager
MenuComponent
Components and Containers:
There are two user-interface classes in the AWT to focus
on: Components and Containers.
Containers
Containers(Frames, Dialogs, Windows and Panels) can contain components
and are themselves components, thus can be added to Containers. Containers
usually handle events that occurred to the Components, although nothing
prevents you from handling events in the component. In short all classes
derived from Container can be one.
The method of handling events in the Container(i.e Frame) is preferred over
the latter, since we want to centralize event handling. If you don't want to
handle events in one common area of code, then you must sub-class every
Component you create an instance of and override its action() or
handleEvent() method.
public class TextEditor extends Frame
{
Button myButton;
public TextEditor()
{
...
setTitle("Text Editor")
setLayout(new BorderLayout());
setBackground(Color.orange);
myButton = new Button("Hit This");
add("Center", myButton);
pack();
show();
}
public boolean handleEvent(Event evt)
{
if("Hit This".equals(evt.arg))
{
System.out.println("He hit me");
return true;
}
}
}
This is another method of event handling. The event is handled in the
Component rather than the Container. First we must sub-class Button.
public class MyButton extends Button
{
...
...
public boolean action(Event evt, Object arg)
{
if(evt.target == this)
{
System.out.println("He hit me");
return true;
}
}
}
public class AnotherTextEditor extends Frame
{
MyButton anotherButton;
public AnotherTextEditor()
{
setTitle("Another Text Editor")
setLayout(new BorderLayout());
setBackground(Color.white);
anotherButton = new MyButton("Hit This");
add("Center", anotherButton);
pack();
resize(300, 300);
show();
}
}
All Containers have common functionality, due to the fact they are derived
from Container which includes many pre-defined event handling
methods(called callbacks). These events are useful for handling user input in a
specialized(i.e sub-class or derived) Container class where you'd override the
default behavior such as the appearance(i.e font, color, etc.) by overriding the
methods.
A quick-and-dirty summary of common methods:
add(Component)
add(String, Component)
remove(Component)
getComponents()
setLayout(LayoutManager)
getLayout()
Every Container Is-A Component since it is derived from Component, thus it
can also behave and be used like an Component. All of the methods in
Component can be used in a Container.
Components
Components are generally the stuff that the user interacts with. The meat and
potatoes of your application. You'll need to display Windows and Buttons.
You'll want Lists within Windows. You'll want the user to enter some
text/input. You'll want easy access to features and functions. Components
will do that for you.
Components are Buttons, TextAreas, Scrollbars, etc. in other words the
visible UI controls that the user interacts with, all of which have been added
to a Container. Anything that is derived from the class Component can be one.
p
A quick-and-dirty summary of common methods:
getBackground()
setBackground(Color)
getFont()
setFont(Font)
mouseDown(Event, int, int)
show()
resize(int, int)
paint(Graphics)
update(Graphics)
move(int, int)
Layouts:
How Components are "laid out" within a Container is described by the
LayoutManager class. Since the LayoutManager class is abstract, we can not
use it directly. You must sub-class it and provide your own functionality or
use a derived class of LayoutManager(i.e BorderLayout, CardLayout,
GridLayout, etc) already created for you.
There are man different layout schemes, but the ones pre-defined for us are






BorderLayout This scheme lays out the Component in 5 ways
1. North - Northern part of the Container
2. South - Southern part of the Container
3. East - Eastern part of the Container
4. West - Western part of the Container
5. Center - Centered in the Container
CardLayout - Allows for what Windows programmers have called for
years "tabbed dialogs" or dynamic dialogs(now available on all versions
of Netscape).
GridLayout - Allows for the layout of Components in a grid -like
fashion rather than "North" or "Center".
GridBagLayout - HTMLTable-ish style of layout
FlowLayout - Allows for Component to be laid out in a row(or flow)
and aligned(left, right, center).
None - No layout, the Container will not attempt to reposition the
Components during a update.
To use a layout we must call setLayout() for the Container with an instance of
a LayoutManager(since LayoutManager is abstract, a sub-class will do).
Using each layouts is different. For BorderLayout you specify the type of
layout(North, South, etc.) by passing a string(i.e "North", "South", etc to the
method add() in a Container.
i.e
add("Center", myComponent);
adds myComponent to the Container and centers it. With other layouts, the
first String parameter is different.
Using Components and Containers
Like all Java classes, to use a class from the AWT we need to create an
instance of it via "new".
add(new Button("Hello"));
Button b = new Button("World");
add(b);

The first add creates a new instance of a Button before adding it to the
Container. To a C++ programmer, this is bizarre. "new Button" never
gets assigned to a variable, so you can't delete it. When do you delete
the Button? Never. Java has automatic garbage collection and will free
the memory up when the Button is no longer used(i.e b = null and
calling gc() may remove it).
You can handle events given the label of the Component, thus new
Button("Hello") makes perfect sense to a Java programmer.

The second add(), adds the previously created component 'b'(a Button)
to the Container.
Event handling
Event-handling? Geez don't I just poll and grab user-input?
No, this is Java and how the GUIs it runs under operate. GUIs and
Windowing systems use the event-driven model rather than the old
procedural-grab-the-input-yourself model. The OS is the one polling for
events. When it finds ones, it tells you what has happened. If you say, "bah, I
don't care about that event". Fine, the OS handles it with its own default
handler, otherwise you better do something with it or you get the default,
which maybe nothing at all.
Here are the some of the events you will need to handle. This list of all events
your application will probably need to handle is in the Event's class
documentation.
1.
2.
3.
4.
ACTION_EVENT
MOUSE_DOWN
KEY_PRESS
WINDOW_DESTROY
ACTION_EVENT occurs when you press a button, select a menu, etc.
To handle ACTION_EVENT you have two choices
1. Handle it handleEvent()
2. Handle it in action()
Both are located in the Component class so all derived classes have these
methods and you should override them to provide your own custom
behavior.
The following examples shows you how and why...
public boolean handleEvent(Event evt)
{
switch(evt.id)
{
case Event.ACTION_EVENT:
{
if((Hey I've been hit " + n + "times).equals(evt.arg))
{
return true;
}
// Here evt.target contains the target
// i.e java.awt.MenuItem[label=Quit]
// evt.arg contains the label of the button pressed
// or menu item hit
}
default:
return false;
}
}
The same thing came be accomplished with action(evt, arg), because when an
ACTION_EVENT occurs action() is called.
public boolean action(Event evt, Object arg)
{
if(("Hey I've been hit " + n + "times").equals(arg))
{
return true;
}
return false;
}
As you can see, even if the labels change you can still receive the event. The
above is a button that changes everytime you hit it. But this isn't the only way
to handle events. In fact you can compare objects instead of labels such as
if(evt.target == myButton).
public boolean handleEvent(Event evt)
{
switch(evt.id)
{
// Examples of what can be handled
case Event.KEY_PRESS:
case Event.HOME:
case Event.WINDOW_MOVED:
return true;
// ...
default:
return false;
}
}
Also you can override a sub-class's method handler such as keyDown(),
mouseDown() to provide your own event handling code. For example a
specialized(sub-class) version of a TextArea that overrides
mouseEnter() can determine when the mouse enters the Component
and thus can decide to hilight the text if needed.