9.1 Simulating a Desktop

Some GUI applications keep their entire interface in a single root window, which looks like a desktop environment and contains internal "windows" and icons, elements you'd find on the actual desktop. This style of interface was first used in early versions of the Windows operating system because, at that time, the operating system didn't support multiple, overlapping real windows for each application, so there was no alternative.

While there are still a few special circumstances in which this kind of interface is actually desirable (for example, if you're creating an emulation of another computer or a virtual environment and want to keep that world clearly distinct in its own window), most applications would be better off using real windows on the actual desktop.

Applications that stick to a virtual desktop interface out of habit do their users a disservice in a number of ways. Because their internal frames (simulated windows) are restricted to exist within the application's root window, the user has to compromise between making that window very large so there is room to position the application's windows in a convenient way, and keeping it small so that the windows of other applications can be seen and accessed conveniently. It's usually impossible to come up with a happy medium. The user is also prevented from overlapping windows of this application with windows of any other application, even if this would provide a better workflow.

Most of the perceived advantages of using a simulated desktop environment in a typical application can be achieved in a better way by thoughtful use of application palettes and the positioning of separate windows. If (despite all these caveats) it turns out that you do need to create and manage your own desktop in a window, Swing can accommodate you.

In this chapter, we'll look at a collection of classes Swing provides to allow you to create this type of application in Java. At the end of the chapter, we'll provide a large sample program that shows how to implement a variety of useful features.

9.1.1 Overview

Before looking at each of the classes involved in the Swing desktop/internal frame model, we'll take a moment for an overview of how they all work together. Figure 9-1 shows the relationships between the classes we'll be covering in this chapter.

Figure 9-1. Internal frame and desktop class diagram

A JInternalFrame is a container that is similar to a JFrame. The key difference is that internal frames can exist only within some other Java container. JInternalFrame implements the following three interfaces: Accessible, WindowConstants, and RootPaneContainer.

Each internal frame keeps a reference to an instance of the static inner class called JDesktopIcon. Like real frames, JInternalFrames can be iconified. JDesktopIcon is the class responsible for taking the place of the frame when it is iconified.

Though not required, JInternalFrames are typically used inside of a JDesktopPane. JDesktopPane is an extension of JLayeredPane that adds direct support for managing a collection of JInternalFrames in layers. JDesktopPane uses an object called a DesktopManager to control how different behavior, like iconification or maximization, is carried out. A default implementation of this interface, DefaultDesktopManager, is provided. We'll see how all of this functionality is broken down as we cover the various classes and interfaces involved.

One more thing to notice about Figure 9-1 is that JInternalFrame supports a type of listener called InternalFrameListener. This interface contains methods like those defined by the AWT WindowListener class, with slightly different names, using InternalFrameEvents rather than WindowEvents as input.