The Standard Widget Toolkit (SWT) — Java UI at its Best (Part 1)
When I first started coding so many years ago, I quickly became a passionate about UI development. Later, I switched to the backend side and worked a lot with Java for years. At some point, I needed to combine both and found SWT. It was love at first sight.
In this article series, I’ll share with you my various experiences through a deep dive into the Standard Widget Toolkit.
So let’s start with an overview …
The SWT is a user interface (UI) toolkit for Java that allows to use native UI widgets from the underlying operating system (OS) in a Java application. Thus, SWT dialogs and windows will look like native applications and have the familiar look and feel of the OS.
Java Swing (Sun Windowing) toolkit on the other hand, renders all UI widgets by itself. That is the reason Swing applications always have a weird and unfamiliar look. This is a huge advantage of SWT applications which cannot be distinguished from native applications.
SWT comes as a simple library (JAR) that can be used within usual Java projects. It includes Java classes for all the various components (dialogs, widgets, layouts, resources, …) and also a native part for the different operating systems (e.g. DLL on Windows, JNILIB on Mac OS).
That means, for distribution, the corresponding library has to be bundled with the executable (JAR) for each targeted OS.
SWT is available for Windows, Linux and Mac OS. It is maintained by the Eclipse Foundation and has for instance the well-known Eclipse IDE built upon it.
Combined with tools like Jar2Exe or Launch4J, you’re able to create native executables for different operating systems. The executable can either use the system’s Java installation or include a bundled JRE.
Along with an installer like NSIS, you can produce ready-to-use / out-of-the-box setups.
Okay so far. Now let’s check the general concepts SWT is following …
Dialog design in SWT is pretty straight forward, since it’s basically writing regular Java code. First, we have to apply a layout (manager) to the dialog’s surface (a shell or a composite). Then, all the desired widgets are added to the dialog’s surface and optionally configured to specify concrete position and behavior on it (by means of their individual layout data).
During runtime, those widgets will arrange themselves on the surface based on the concrete layout and layout data. Due to using a layout, dialogs can easily be made responsive when styled as resizable.
Designing a dialog by writing code can be a very abstract task, especially for beginners. But when you get used to it, you’ll notice that you are getting absolute control over the dialog.
As an alternative, dialogs can also be designed using visual editors embedded in an IDE like Eclipse if you prefer. In that case, it is the visual editor that will generate the corresponding dialog code. A popular designer is for instance WindowBuilder.
That was easy. Let us move forward into more technical aspects …
Each widget is constructed on a parent surface therefore becoming a child item of said surface. A surface, as mentioned earlier, is either a shell or a composite. A shell represents a window shown by the OS, whereas a composite is a container that can host other widgets or composites.
This means for instance, that it is possible to create your own widgets by combining multiple widgets into a complex one. Those widgets can then be used like built-in widgets and be placed almost anywhere on the surface.
User interaction in SWT is pretty simple and mostly covered through a bunch of listeners for the various input events. An event loop has to be started by the application to transfer user input from the OS to the application (the SWT event system). Then, registered listeners are notified on desired events allowing to process user input.
One main difference to usual Java programming is that created resources (images, fonts, colors, GC, …) have to be disposed explicitly. Otherwise the application is ‘leaking’ resources. Due to the fact that there is a limit in the number of resources a platform can allocate, ‘leaking’ might result in a state where that platform cannot allocate anymore resources.
That was it for the theory. Stay tuned - next up is a sample application …
Continue with Part 2.
