In this article, we will talk about Java J2SE graphical user interface (GUI) libraries. We will adopt a programmer's viewpoint in our discussion. We assume the reader is familiar with the basics of the Swing library and wants to explore the SWT technology.
We will discuss two Java GUI libraries:
- Swing—The reference GUI toolkit for J2SE.
- SWT—This library has been developed by IBM as a part of the Eclipse platform.
Eclipse is an open-source, IBM-sponsored, fully extensible IDE, built using Java and SWT. SWT originated as Eclipse's GUI library, but it can be used outside it as a an alternative GUI library to both Sun's AWT and Swing.
In the following section, we will introduce the basics of SWT. We will assume the reader is familiar with Swing. Finally, we compare SWT and Swing.
SWT
SWT (Standard Widget Toolkit) is a graphics library and a widget toolkit integrated with the native window system (especially with Windows but Linux and Solaris are supported as well). Despite the tight integration with the native target platform, SWT is an OS-independent API. SWT can be seen as a thin wrapper over the native code GUI of the host operating system.
At a higher level of abstraction, also a part of the Eclipse platform, lies JFace. This is a GUI library, implemented using SWT, that simplifies common GUI programming tasks. JFace is independent of the given window system, in both its API and implementation, and is designed to work with SWT, without hiding it. For brevity, we will discuss only SWT here.
Introduction
The design strategy of SWT was focused on building a simple, essential library that would produce GUI applications closely coupled to the native environment. SWT delegates to native widgets for common components (such as labels, lists, tables, and so on) as AWT does, while emulating in Java more sophisticated components (for example, toolbars are emulated when running on Motif) similarly to Swing's strategy.
SWT has been designed to be as inexpensive as possible. This means (among the other things) that it is native-oriented. Anyway, it differs from AWT in a number of details. SWT provides different Java implementations for each platform, and each of these implementations calls natively (through the Java Native Interface, JNI) the underlying native implementation. The old AWT is different in that all platform-dependent details are hidden in C (native) code and the Java implementation is the same for all the platforms.
Resources
An important difference from normal Java programming is the way OS-dependent objects are managed in SWT. Swing emulates a large part of such objects (such as widgets, for instance) in Java, leaving the disposal job to the JRE garbage collector. This saves a lot of complexity for the programmer but this lack of control can lead to some unexpected issues, especially with cross-platform development.
SWT designers chose a different approach, obliging the developer to explicitly dispose of OS-dependent objects in the application code. SWT has been designed with efficiency in mind, so handling explicitly OS resources becomes an occasion to promote efficient programming and not just a necessity. Resource disposal is needed to free the OS resources used by the SWT application. Such OS resources need to be explicitly de-allocated by invoking the dispose method.
In practice, disposing of objects is a delicate business and it can lead to unpredictable results whenever another object tries to access an already disposed item.
The Basic Structure of an SWT Program
As already said, an SWT program relies upon the native platform resources (wrapped by the Display class, as we will see later on) both in terms of allocated resources (such as colors, images, and so on) and as regards the event mechanism. As regards event handling, in SWT there is only one thread that is allowed to handle native user interface events.
We now see the basic structure of an SWT program. This will help us understand SWT's basic architecture.
There are two basic classes used in any SWT application, the Display and Shell classes. Instances of the Display class are responsible for managing the connections between SWT and the underlying operating system, enforcing the SWT models (for colors or images, for example). The Shell class instead represents windows managed by the platform-dependent desktop manager.
Typically, an SWT program will first create a local resources manager (an instance of the Display class) and attach all the needed widgets to one or more Shell objects. Listing 1 shows this typical mechanism.
Listing 1: A snippet of code showing the use of the Display and Shell classes.
00: Display display = new Display();
01: Shell shell = new Shell(display);
02: //GUI code here
03: shell.open();
04: while (!shell.isDisposed()) {
05: if (!display.readAndDispatch())
06: display.sleep();
07: }
08: display.dispose();
09: }
10: }
To fully understand the code in Listing 1, one should understand the readAndDispatch method of the Display class. Such a method reads an event from the operating system's event queue, dispatching it appropriately. It returns true if there is additional work to do, or false if the caller can sleep until another event is placed on the event queue.
The loop at lines 4-9 in Listing 1 is typical of SWT applications. It takes care of forwarding all underlying platform events to the SWT application until the shell is disposed and the program can exit the event loop.
Basic Controls
Some of the basic components (or controls, as they are called in SWT) are the following:
- Button. This component is the well-known button component used in toolbars, forms, and so forth.
- ComboBox. This widget is the well-known combo box component.
- Label. This component represents a (non-selectable) object that displays a string or an image.
- List. This widget represents a basic list component.
- ProgressBar. It shows a progress indicator.
- Sash. It is the Swing equivalent of a JSplitPane. It is a widget that can be dragged to resize two areas in a GUI.
- Scale. This component implements an editable GUI item representing a range of continuous numeric values.
- Slider. This component represents an editable object that stands for a range of discrete, numeric values.
- Table. This component represents a basic table.
- Text. This component represents a basic text area.
- Tree. This component represents a basic tree widget.
- StyledText. This component represents a text area with styled fonts and other advanced attributes.
eKit: Essential HP Solutions for Your Data Center
IE 7
Firefox 2.0
AJAXWebApps.gif/32363637336631303438326462323530)
AJAXWebApps.gif/32363637336631303438326462323530?_RM_EMPTY_){kind=small}