Section 8 : The java.awt Package

Write code using component, container, and LayoutManager classes of the java.awt package to present a GUI with specified appearance and resize behavior, and distinguish the responsibilities of layout managers from those of containers.

Painting in Java

Painting on a component is accomplished by making calls to a graphics context, which is an instance of the Graphics class. A graphics context knows how to render onto a single target. The three media a graphics context can render onto are:

1. Components

2. Images

3. Printers

Any kind of component can be associated with a graphics context. The association is permanent – a context cannot be reassigned to a new component. Although you can use graphics contexts to paint onto any kind of component, it is unusual to do so with components that already have an appearance. Buttons, Choices, checkboxes, labels, scrollbars, and text components do not generally require programmer level rendering. There are four classes of blank components that have no default appearance and will show up as empty rectangles unless they are sub-classed and given paint() methods:

1. Applet

2. Canvas

3. Frame

4. Panel

The four major operations provided by the Graphics class are:

1. Selecting a color

2. Selecting a font

3. Drawing and filling

4. Clipping

Selecting a color

Calling g.setColor() does not change the color of anything that has already been drawn. It only affects the subsequent operations.

Selecting a font

Setting the font of a graphics context is like setting the color – subsequent string drawing operations will use the new font, while previously drawn strings are not affected. Before you can set a font, you have to create one. The constructor for the Font class is

Font(String fontName, int style, int size);

The first parameter is the name of the font. Font availability is platform dependent. You can get a list of available font names, returned as an array of strings, by calling getFontList() method on your toolkit.

String [] fontNames = Toolkit.getDefaultToolkit().getFontList();

There are three font names that you can always count on, no matter what platform you are running on:

1. Serif

2. SansSerif

3. Monospaced

The style parameter of  the Font constructor should be one of the three:

• Font.BOLD

• Font.PLAIN

• Font.IATLIC

You can specify a bold-italic font by passing Font.BOLD+Font.ITALIC  as a style parameter.

Drawing and filling

Every component has its own coordinate space with the origin in the component’s upper left corner.

drawString()

          The parameters x, y specify the left edge of the baseline of the string. Characters with the descenders (g, j, p, q, y etc.) extend below the baseline. By default a graphics context uses the font of  the associated component. However, you can set a different font by calling the graphics context’s setFont() method.

Clipping

Clipping is simply restricting the region that a graphics context can modify. Every graphics context – that is every instance of the Graphics class – has a clip region, which defines all or part of the associated component. When you call one of the drawXXX() or fillXXX() methods of the Graphics class, only those pixels that lie within the clip region are modified. The default clip region for a graphics context is  the entire associated component. There are methods that retrieve and modify a clip region.

To set a rectangular region for a graphics context, you can call the setClip(x, y, width, height) method, passing in four ints that describe the position and size of the desired clip region. Clipping also comes into play when the environment needs to repair exposed portions of a component.

If a frame or an applet contains components that have their own paint() methods, then all the paint() methods will be called by the environment when necessary.

The GUI thread and the repaint() method

The runtime environment creates and controls its own threads that operate behind the scenes, and one of these threads is responsible for GUI management. The GUI thread is the environment’s tool for accepting user input events and for calling the paint() method of components that need painting. Calls to paint() are not generated by the run time. Java programs can make their own calls, either directly (which is not recommended) or indirectly ( via the repaint() method).

Spontaneous painting

Some painting happens all by itself, with no impetus from the program. For example, when a browser starts up an applet, shortly after init() method completes, a call is made to the paint() method. Also, when part or all of a browser or a frame is covered by another window and then becomes exposed, a call is made to the paint(). It is the GUI thread that makes these calls to paint(). Every applet, and every application, that has a GUI, has a GUI thread. The GUI thread spontaneously calls paint() under four circumstances, two of which are applicable to applets:

1. After exposure

2. After de-iconification

3. Shortly after init() returns (applets only)

4. When a browser returns to a previously displayed page containing an applet, provided the applet is at least partially visible.

When the GUI thread calls paint() it must supply a graphics context. Every graphics context has a clip region. The GUI thread makes sure that the graphics contexts that get passed to paint() have their clip regions approximately set. Most often, the default clip region is appropriate. However, when a component is exposed, the clip region is set to be just that portion of the component that requires repair. If only a small region of the component was exposed, then the clip region insures that no time is wasted on drawing pixels that are already correct color.

The repaint() method

There are times when the program, not the runtime, should initiate painting. This usually happens in response to input events. It is a good rule of thumb to do all drawing operations in paint(), or in methods called from paint(), so that the GUI thread expects paint() to be able to correctly reconstruct the screen at any arbitrary moment. The way to give the GUI thread what it expects is to remove all drawing code from event handlers. Event handlers should store information in instance variables, then cause a call to paint(). The paint() should use the values of the instance variables as instructions on what to draw.

There is a method update(Graphics g) of Component class, which clears the component to its background color and then calls paint(). You can override this method and simply call paint() inside update() so that it does not clear the previously drawn figures.

The repaint() method schedules a call to update(). All this means is that a request flag is set in the GUI thread. Every 100 milliseconds the GUI thread checks the flag. If the flag is set, the GUI thread calls update() and clears the flag. No matter how many requests are made during any 100 ms period, only a single call is made to update().

Images

Images are off–screen representations of rectangular pixel patterns. You can create, modify and draw them to the screen or to other images. There are three ways to create an image:

1. Image img = createImage( int width, int height); // creates an empty image.

2. GetImage( URL fileUrl);

3. GetImage( URL dirUrl, String path);

The last two methods create an image based on the information in a gif or jpeg file. The Applet and Toolkit classes both have getImage().

Images have graphics contexts. So, to modify an image get a graphics context for the image to be modified and call methods like getGraphics().

section8-1-1 | section8-1-2 | section8-1-3 | section8-2

Sections : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11

Home | Blog | Java | Jokes | Poems | Musings | Site Map | Kudos | Downloads | Useful Sites | Interesting | System Setup | Contact  

 Number of Pages viewed on this site since January' 2003 :

For any queries, comments or suggestions, write to me .

This site never compromises your privacy, please read this site's privacy policy.