< Zurück | Inhalt | Weiter >

17.3.1 Step 1: Convert the Class Members

We are going to tackle converting BudgetPro.java from Swing to SWT. In real life, this is an exercise you are unlikely to have to carry out. You will more likely write your GUI applications from scratch. But going through the conver- sion provides a useful roadmap for talking about the architecture of SWT; it teaches you SWT in terms of a class library with which you are already familiar.

First off, we change the packages imported at the start of the file. Remove all of the awt and swing packages. If you are using an IDE, this should flag every single line of code that touches the GUI as an error. This can be a big help when you are doing a mass conversion like this. When you have killed all the compile errors, you know you are well on your way to completing the conversion.

Replace the import statements with the imports you are likely to need for your SWT application. These are:


import org.eclipse.swt.*;

// The static SWT class, which contains a number of constants.


import org.eclipse.swt.widgets.*;

// The widgets library. Almost all your display elements are here. import org.eclipse.swt.events.*; // Event handlers

import org.eclipse.swt.layout.*; // Layout managers


We will go into these families of classes in more detail as we convert the members and methods of BudgetPro.java.


The next step is to convert the GUI members of the class from the Swing classes to their SWT counterparts. Of course, SWT requires the Display class, which has no analog in SWT, so we add a Display type member named disp just ahead of the frame member.

Next, we change the type of frame from JFrame to Shell. We could re- name the member,10 but why add to our typing burden? The name is still clear and meaningful, even if it doesn’t match the SWT name.11 There’s more to it than just changing the type, however. The constructor call for the JFrame doesn’t match any constructor for Shell. In fact, the Shell constructor re- quires a Display object argument, and all subsequent constructors for widgets and controls require a Composite as an argument.

This is a key difference between Swing and SWT. Swing allows you to build GUI components in arbitrary order at arbitrary times and then join them up to the GUI with an add() method call. SWT instead requires that you link your components up to the GUI element they belong to when they are construct- ed. There are good reasons for this difference. Remember that SWT allocates native objects and memory that Java’s garbage collector cannot recover. Because of this, SWT makes the promise that if you call the dispose() method on any SWT object, it will dispose of it and everything it contains. That allows you to clean up all resources from an SWT program by calling dispose() on the top level Display object. If SWT allowed you to build GUI structures indepen- dently and then graft them onto the hierarchy, it could not keep this promise. For this reason (amongst others) SWT objects are always built in a fairly rigid top-down manner.12

The most direct consequence of this is that we have to get rid of the con-

structors on these declarations. We’ll start construction in the main(). So, away with the constructors for the GUI elements. We now need to change the JButtons to Buttons and the JLabels to Labels. Again, if you are using a dynamic IDE, you should see your error count skyrocket with these changes


image

10. If you are using Eclipse, this is easily done throughout your code with the Refactoring feature.

11. All right, I’m being lazy. Write your own book if you don’t like it.

12. In some ways, this greatly simplifies SWT programs, but at the cost of some reusability. With Swing, you could construct a panel or other GUI element and reuse it in many places. You can achieve the same thing in SWT by encapsulating such a construct in its own class and passing in a parent to the constructor, but this is a bit more bulky and complex than the Swing way.


image

Key SWT Abstractions

Composite is one of the key abstractions in SWT. Any control that may contain other controls is a Composite.

Here’s a quick rundown of the key abstract classes and interfaces in SWT, along with the basics of the functionality they embody:

• A Widget is the abstract superclass of all user interface objects in SWT. At this level the methods exist that create, dispose, and dis- patch events to listeners. Every single class we use in this chapter, with the exception of event handlers and layout managers, is a Widget.

• A Control is the abstract superclass of all windowed user interface classes. This is almost all of the UI classes, either by direct descent or through classes such as Sash or Scrollable. All constructors for Control classes require a Composite parent class as a construc- tor argument.

• A Composite is a Control which is capable of containing other Controls. One direct descendant of Control which is very similar to the Swing JPanel is Group.

The relationships and the power of these abstractions will become clear as you work with real-life examples.


(well, maybe not really skyrocket, since the import changes have already produced a lot of errors right off the bat).

Finally, we remove the AbstractTableModel member. SWT has a simpler (and more limited) table functionality that we will discuss later.