Window Systems and Graphics

Introduction: Window Systems, some history

Window Systems

Frames and Components
When we look at the screen of a typical window system, we see a collection of rectangular regions which I will call frames. Each frame corresponds to a program running on the system, though the mapping is not one-to-one. Each program can have 0, 1, or several frames associated with it. By typing or mousing, we can send input to the program associated with the current frame. The program can respond by drawing text or graphics in its frames (or creating new ones).

Each frame is often subdivided into a number of rectangular areas, which I will call components. Examples of components are buttons, menus, menubars, text input fields, and areas in which text and graphics are drawn. These components often have particular behavior in response to mouse clicks, etc. However, these components are bound in some deep way to the enclosing frame. For example, all components of a frame move together when the frame is moved.

We can also use the mouse to move a frame around, resize the frame, Iconify the frame, kill the frame, select a frame, bring a frame to the foreground so it is not covered by other frames, etc.

Window Systems and Operating Systems
There is a tremendous amount of technology behind the scenes that is making this picture work. For each frame, three different entities are interacting to produce the behavior we see on our screens: the program attached to the frame, the operating system, and the Window System which is mediating between them.

Each program is only responsible for the contents of its own frames. It is in general, not resposible for where they are on the screen, whether they are on top or buried, etc. Each program wants to treat its frames as a collection of rectangular areas, independent of any other program's frames.

The operating system is responsible for managing attached hardware. In particular, the mouse, the keyboard, and the screen. It tracks low level motion, click, and keypress events, and sets pixels on the screen to particular colors.

A digression--Pixels and Screens: The image on your screen is made up of a rectangular array of dots which can be set to some color by the computer's graphics hardware. These dots are called pixels. Depending on the computer, monitor, and graphics card, the screen will consist of different sized arrays; for example 1024x800 pixels, 1600x1200, 480x760.

The Window System is an entity that mediates between the operating system and the programs to manage the global resources of screen, mouse, and keyboard, while giving each program the view that it is connected to a mouse, keyboard and some number of frames. It is the window system that is responsiable for placing frames on the screen, moving them, iconifying them, killing then, selecting them, uncovering them etc. It also decides which frame--and therefore which program--each mouse event and key press belongs to. The main abstraction the Window System supports is called, naturally, a Window. Windows correspond to rectangular areas of the screen managed by the Window Systems. Both the frames and components discussed above are windows. In a typical application, each button, menu, scrollbar, etc. is its own window. (At least in most implementations; sometimes there are attempts to cheat for efficiency).

Frame windows are generally treated specially by the window system in that they are given borders, and a title bar with close and iconify icons, and all the other stuff for moving and resizing. (Of course a program can request this stuff be turned off).

Inside a frame, a program's windows are organized hierarchically. This hierarchy usually follows geometric enclosure. Child windows appear inside parent windows. Note: this hierarchy of windows is NOT the inheritance hierarchy of the various window types.

In general, the program is responsible for drawing the contents of its windows and reacting to mouse and keyboard events appropriately. For windows of common functionality, like buttons, there are libraries that support this functionality so it doesn't have to be duplicated. Some of these implement GUI components, and are often called widgets. There are other window types whose sole function is to organise the layout of their children. These are usually called container or layout windows.

Windows in Java
OK enough background. Let's write a program in Java that creates a frame Window.

The Java class that will do this for us (using the Swing GUI implementation) is JFrame. We will subclass JFrame to make a frame with the behavior we want.


// Need to import these
import javax.swing.*;
import java.awt.*;
import java.awt.geom.*;

/**
 * Basic code to put up a frame.
 */

class MyFrame extends JFrame{

    public MyFrame(){
	setTitle("MyFrame");
	setSize(200,200);        // size in pixels, must set: defaults to 0,0
	// Magic to get program to quit on Frame window close
	setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    }

}

public class FrameTest{

    // OK let's have our main() create a frame.
    public static void main(String[] args){
	// Create new frame
	MyFrame myframe = new MyFrame();
	// Show frame
	myframe.show();
    }
}

When I compile and run this program, it opens a frame whose size is 200x200 pixels with title "MyFrame". Notice I can move it, resize it, iconify it, close it; it appears in the taskbar, I can lower or raise it. All without doing any work. The Window System handles it all for me. Is this cool or what?

Scaling and Size Issues
When I created this frame, I made it the fixed size 200x200. On my office screen, which is about 1000x800 pixels, this takes up about 1/20 of the screen area. On a smaller screen, say 400x600 pixels, is would take up 1/6 of the screen. This is important to remember any time you are writing a GUI application. It may be run on a number of different screen sizes and you should do your best to make it work well on all. Java ( and most Window systems) have facilities for querying the size of the screen, so you can size your window appropriately.

Sizing issues go beyond how big to make the frame window. Clearly you can fit more stuff into a 400x400 window than a 200x200 window. The application developer must decide how best to adjust to the smaller area, whether to scale everything, pack things close together, or simply omit things. This issue also appears when the user resizes the window. The program must adjust to the new size to make it look good (or simply not allow re-sizing).

Drawing
Today's topic is graphics, so let's draw something. It is poor form to draw directly into the JFrame. What we need is a component for drawing into. In Java Swing, this component is usually JPanel. Again we must subclass JPanel to make a panel that behaves the way we want.
class MyPanel extends JPanel{

	public void paintComponent(Graphics g){
	    super.paintComponent(g);
	    g.drawString("Hello World",50,50);

	}

}
More Drawing

The only way to really learn to use these tools is to try them. Explore nad have fun.