User:Boldingd/Sandbox/GuiProgramming/Starting a Project

Starting a Gui Project

Starting a SWING Project

Let us first consider how to start a Swing project.

A reasonable first step is to create a window; we will after all need some kind of container or display into which we can place contents. In Java SWING, the class that represents a top-level window is known as a JFrame. We can create a JFrame simply enough:

import javax.swing.JFrame;

public class StartingSwing {

    public static void build() {        
        JFrame frame = new JFrame("title");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        frame.pack();
        frame.setVisible(true);
    }

    public static void main(String args[]) {
        javax.swing.SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                build();
            }
        });
    }

}

Some of this is simple enough: the JFrame class represents a window, and the instance that we have created, frame, will represent a specific window. We may reasonably assume that the single String argument here provided, which we have specified as "title" is the title that we wish to give the window.

The setDefaultCloseOperation specifies what we want done when the user clicks the "close" button on our window. In Swing, the default action is to hide the window; if we want event processing to cease and our program to exit, we must specify this explicitly. This might seem odd, but consider that a program might have multiple windows, or might include background processes that we do not with to terminate; we would not wish to dispose of all of these resources simply because one window was closed.

Similarly, frames do not necessarily start out visible; a large GUI program might contain many frames. To save time later, it might be convenient to construct many frames (holding different components of our application) when our programs start, even if we may only immediately make use of a few of them. For this reason, we need to tell the system to mark our particular frame as visible.

The pack function requires some explanation: simply, it computes the layout of our frame. The frame we have constructed above is empty - we have not specified any contents. An empty frame is not particularly useful; generally, we will fill a frame with 'widgets' to display information and allow the user to interact with the application. Swing will need some kind of policy to determine where on the screen our widgets will be placed, how large they will be, and how their sizing and positioning will change as the user interacts with the application - if the user resizes the window, for example. The pack function instructs the Swing library to compute the initial positioning and sizing for whatever widgets that we may have placed into the frame - in this case.

Finally, we note the somewhat odd contents of the main function. Recall that, in general, in order for our program to process events, somewhere there must be an 'event loop' running. In the specific case of Swing, the system arranges to start an event loop for us - it does so whenever we show() a frame. This event loop is started in its own thread, a fact which creates some complications for us - it requires us to deal with potential concurrency issues.

As a general rule (the reasons for we shall revisit), operations on the components of a GUI need to occur in the thread running the event loop. This includes 'building' the GUI in the first place, and so we need to ensure that our GUI construction routine occurs on the event-loop thread. This is what is happening in our main loop: we are declaring an instance of the Runnable class, which represents a Thread in Java, we are arranging for that Runnable to call our GUI-building function, and we are asking the system to perform that operation on the event-dispatch thread. The notation is somewhat dense; this is in part because it does not necessarily serve our purposes to completely unpack this now. We will revisit the issue of multithreading in GUI applications somewhat later.