1. Why use SWT?
SWT is an IBM development cross-platform GUI development kit. As for why IBM costs yourself to develop a GUI kit, rather than using Sun's existing Java GUI framework composed of AWT, SWING, JAVA 2D, Java 3D, etc., then says the length. (Remember to read a post on SWT origin on a BBS).
Prior to SWT, Sun has provided a cross-platform GUI development toolkit AWT (Abstract Windowing Toolkit). Although the AWT framework is also used by native widgets, it has not been able to break through the LCD problem. The LCD problem has led to the loss of some major platform features. If you don't understand (in fact, I didn't understand), in other words, if the platform A has a window component (Widgets) 1-40, the platform B has window components (Widgets) 20-25, then the cross-platform AWT framework is only Can provide intersection of these two widgets.
To solve this problem, Sun creates a new framework again. This framework is no longer using native window components, but uses the emulated widgets. This method solves the LCD problem and provides a rich window component set, but it also brings new problems. For example, the appearance of the SWING application is no longer similar to the appearance of the native application. Although these Swing applications have been improved by these Swing applications in JVM, they still have performance issues that have their native counterparts. Also, the Swing application consumes too much memory so SWING is not suitable for some small devices such as PDA and mobile phones.
IBM has been trying to completely solve the above problems from the AWT and SWING frameworks. In the end, IBM created a new GUI library, this is SWT. The SWT framework accesses the native window components via JNI. If a window component cannot be found on the host (Host) platform, SWT will automatically simulate it.
2. The composition of the SWT application
The basic component of an SWT application is a display interface (display), the command interface (SHELL, enters and initializes the running initialization) and window components (Widgets). Display is responsible for managing event loops and controls communication between UI threads and other threads. Shell is a window managed by the operating system window manager in the application. Each SWT application requires at least one DISPLAY and a shell instance equal to 1.
Figure 1: See the SWT application from different angles
Figure 1 shows the SWT application from a different angle. The picture on the left is a simplified UI object inload diagram. The middle diagram shows the container structure of the UI object. The graph on the right is a created UI appearance.
If an application uses multiple threads, each thread is used by the Display object assigned to itself instance. The programmer can use the static method Display.getCurent () to get an instance of the current activity of the Display object.
Shell is used to express windows in a specific operating system. Shell can maximize, minimize or normalize. There are two types of shells. The first is the high-level shell, which is a sub-window of Display, and it is also a main window. Category 2 is a dialogue shell, which exists in other shell windows. The shell window finally became the type of the above, to see what style bit is passed to the shell constructor when creating the shell. The default value of a shell is Dialogshell. That is, if you don't have a parameter, that is the default is a conversation shell. If a Display object is given to the parameter, the shell will be a high-level shell. Some of the properties of the widget must be set in the initial period of creating them. The properties of these widgets are the style bits in the foregoing (STYLE BITS). In the SWT class, the style bit is defined as a constant. E.g,
Button button = new button (shell,
SWT.PUSH | SWT.BORDER acts as a styling bit parameter.
3. Environment settings before SWT development
In order to develop SWT applications, you need to add the SWT library to classpath and set the necessary environment variables.
First, you have to find the Swt.jar library file in the eclipse_home / eclipse / plugins / org.eclipse.swt.win32_2.1.0 / ws / win32 directory. Note that the "org.eclipse.swt.win32_2.1.0" directory here is related to the version of Eclipse. I can't find the file search function. Then open the following window Project-> proties-> javabuildpath-> libraries-> add variable -> eclipse home -> Extend Add the SWT.jar file to the classpath.
Then you will definitely compile this SWT application. However, the operation exception shown below will appear. This abnormality is that the SWT.jar library uses the original branch. You need to set up java.library.path environment variables to use the native libraries in Java.
The output of console is as follows:
java.lang.UnsatisfiedLinkError: no swt-win32-2136 in java.library.path at java.lang.ClassLoader.loadLibrary (Unknown Source) at java.lang.Runtime.loadLibrary0 (Unknown Source) at java.lang.System.loadLibrary (UNKNOWN SOURCE) AT Org.eclipse.swt.internal.library.loadLibrary (library.java:108) at Org.eclipse.swt.internal.win32.os.
Project "-> arguments -> VM Arguments. Enter in" VM Arguments "
-Djava.library.path = c: /eclipse/plugins/org.eclipse.swt.win32_2.1.0/OS/WIN32/X86
Note To enter the path where your own swt.jar is located.
Tips: Load the native store: If you need to load your own application, you can use the runtime.getplatform.loadLibrary ("libraryname") method.
Compile your app again, this time it passed.
