View RSS Feed

My Java Tips

Introduction to Standard Widget Toolkit

Rate this Entry
by , 11-10-2011 at 06:18 PM (3168 Views)
AWT (the Abstract Windowing Toolkit) was the first Java GUI toolkit, introduced with JDK 1.0 as one component of the Sun Microsystems Java standard. The relatively primitive AWT wrapped Java code around native (operating system-supplied) objects to create GUI elements, such as menus, windows and buttons. AWT was a very thin wrapper around native widgets, exposing developers to platform specific code, quirks and bugs that limited how portable and native-looking applications could be across different computing platforms.

Swing was the next generation toolkit introduced by Sun into J2SE 1.2, and was more object-oriented than AWT. Swing GUI elements are 100% Java, with no native code instead of wrapping around native APIs, Swing calls low level operating system routines to draw the GUI elements by itself.

Around this time, IBM was developing their VisualAge development integrated development environment (IDE), coded in Smalltalk. They decided to open-source the project, which led to the development of Eclipse, intended to compete against other IDEs such as Microsoft Visual Studio. Eclipse is written in Java, and IBM developers, deciding that they needed a toolkit that had "native look and feel" and "native performance" created SWT as a Swing replacement.

The Standard Widget Toolkit (SWT) is a graphical widget toolkit for the Java platform originally developed by IBM and maintained now by the Eclipse Foundation in tandem with the Eclipse IDE. It is an alternative to the AWT and Swing Java GUI toolkits provided by Sun Microsystems as part of the Java standard.

SWT is written in Java. To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using JNI (Java Native Interface) in a manner that is similar to those programs written using operating system-specific APIs. Programs that call SWT are portable, but the implementation of the toolkit, despite the fact that it is written in Java, is unique for each platform.

The toolkit is licensed under the Eclipse Public License, an Open Source Initiative approved open source license.
The Standard Widget Toolkit (SWT) is a widget toolkit for Java developers that provides a portable API and tight integration with the underlying native OS GUI platform.

Many low level UI programming tasks are handled in higher layers of the Eclipse platform. For example, JFace viewers and actions provide implementations for the common interactions between applications and widgets. However, knowledge of SWT is important for understanding how the rest of the platform works.

Portability and platform integration

SWT defines a common portable API that is provided on all supported platforms, and implements the API on each platform using native widgets wherever possible. This allows the toolkit to immediately reflect any changes in the underlying OS GUI look and feel while maintaining a consistent programming model on all platforms.


SWT includes many rich features, but a basic knowledge of the system's core - widgets, layouts, and events - is all that is needed to implement useful and robust applications.

Widget application structure

When you are contributing UI elements using platform workbench extensions, the mechanics of starting up SWT are handled for you by the workbench.

If you are writing an SWT application from scratch outside of the workbench, you must understand more about SWT's application structure.

A typical stand-alone SWT application has the following structure:

- Create a Display which represents an SWT session.
- Create one or more Shells which serve as the main window(s) for the application.
- Create any other widgets that are needed inside the shell.
- Initialize the sizes and other necessary state for the widgets. Register listeners for widget events that need to be handled.
- Open the shell window.
- Run the event dispatching loop until an exit condition occurs, which is typically when the main shell window is closed by the user.
- Dispose the display.

The following code snippet only displays the string "Hello World," it does not need to register for any widget events.

Java Code:
   public static void main (String [] args) {
      Display display = new Display ();
      Shell shell = new Shell (display);
      Label label = new Label (shell, SWT.CENTER);
      label.setText ("Hello_world");
      label.setBounds (shell.getClientArea ()); ();
      while (!shell.isDisposed ()) {
         if (!display.readAndDispatch ()) display.sleep ();
      display.dispose ();
Now I will write about display, shell, parent and children, and style.


The Display represents the connection between SWT and the underlying platform's GUI system. Displays are primarily used to manage the platform event loop and control communication between the UI thread and other threads.

You must create a display before creating any windows, and you must dispose of the display when your shell is closed. You don't need to think about the display much more unless you are designing a multi-threaded application.


A Shell is a "window" managed by the OS platform window manager. Top level shells are those that are created as a child of the display. These windows are the windows that users move, resize, minimize, and maximize while using the application. Secondary shells are those that are created as a child of another shell. These windows are typically used as dialog windows or other transient windows that only exist in the context of another window.

Parents and children

All widgets that are not top level shells must have a parent. Top level shells do not have a parent, but they are created in association with a particular Display. You can access this display using getDisplay(). All other widgets are created as descendants (direct or indirect) of top level shells.

Composite widgets are widgets that can have children.

When you see an application window, you can think of it as a widget tree, or hierarchy, whose root is the shell. Depending on the complexity of the application, there may be a single child of the shell, several children, or nested layers of composites with children.

Style bits

Some widget properties must be set at the time a widget is created and cannot be subsequently changed. For example, a list may be single or multi-selection, and may or may not have scroll bars.

These properties, called styles, are set in the constructor. All widget constructors take an int argument that specifies the bitwise OR of all desired styles. In some cases, a particular style is considered a hint, which means that it may not be available on all platforms, but will be gracefully ignored on platforms that do not support it.

The style constants are located in the SWT class as public static fields. A list of applicable constants for each widget class is contained in the API Reference for SWT.

Submit "Introduction to Standard Widget Toolkit" to Facebook Submit "Introduction to Standard Widget Toolkit" to Digg Submit "Introduction to Standard Widget Toolkit" to Submit "Introduction to Standard Widget Toolkit" to StumbleUpon Submit "Introduction to Standard Widget Toolkit" to Google