Http://www.developer.com/java/other/article.php/10936_2179061_1more.asp?name=80x86&id=66444 Translated an article, compared to the primary, but written very well, Native in the article, such as Native Platform, I have translated into a local. In fact, I first translated something. It is very difficult to grasp the word. I try to search for this word in Baidu, Google, and translate it online into "native". In the case of translation, please refer to the original text, after all, the original text is the best, Chinese is just for reference. I have to declare that this is the first draft, there are a lot of questions, I will change it, everyone must help me.
Swing and SWT: Tell the story of two Java Gui libraries by Mauro Marinilli
Http://www.develop/http://www.develop/http://www.develop/http://www.develop/Http://www.develop/Http://www.develop/Http://www.develop/Http://www.develop/Http://www.develop/Http://www.develop/http://www.develop/Http://www.develop/HTPHP/10936_2179061_1 Translation: 80x86 email: liuxin8312@163.com This article is described in Java The content of the J2SE GUI library. We will be based on a programmer's perspective to discuss the following. We assume that the readers of the article have become familiar with the basic knowledge of the Swing library, and want to learn SWT technology (this is the reason I saw this article 80x86).
We will discuss two Java GUI libraries: 1, Swing-J2se mentioned GUI tools. 2, the SWT-this library is developed by IBM as part of the Eclipse platform (please pay attention to this place 80x86).
Eclipse is an open source, IBM sponsored, fully scalable IDE, built using Java and SWT. SWT originated from the Eclipse's GUI library, but it can also be used out of Eclipse, which is an alternate GUI library for Sun's AWT and SWING.
The following section will introduce the basics of SWT. We assume that the reader is familiar with Swing. Finally, we will compare SWT and SWING.
SWTSWT (Standard Widget Toolkit) is a graphic library or a gadget box combined with local (operating system 80x86) window systems (especially with Windows, but also also supports LINUX and Solaris). Although the SWT is an API that is not related to the operating system. SWT can be seen as a thin layer of wrapper of the local GUI code of the host (Host) operating system. On a higher level of abstraction, there is a JFACE, which is also part of the Eclipse platform. This is a GUI library, implements SWT implementation, used to simplify general GUI programming work. JFACE is not related to a specific window system, which is not related to its API and implementation, designing it is to work with SWT without hiding it. Long-term short say, here we discuss SWT.
Introduction
The design strategy of SWT focuses on building a simple, refined library, which is used to make GUI software that is closely linked to the local environment (and your operating system). SWT Entrusted Native Widgets Generates normal components (such as labels, lists, forms, etc.) just like AWT, you can also use Java to imitate more complex components (eg, imitate the toolbar on Motif) Just like Swing's strategy. SWT has been designed to be as little as possible. This means (with other things ??) it is a platform. In any case, it is different from AWT in many details. SWT provides different Java implementations for each platform, and each implementation calls local (through Java local interface, JNI) fundamentally realized local implementation. Different from the previous AWT is that all platforms related details are written with C (local) code, and Java implementation is the same for all platforms. The important difference between resources and normal Java programming is that the management of system-related objects is made by SWT. Swing used Java to imitate a large part of these objects (such as window parts), left the clear work to the JRE garbage collector. This saves the programmer to save a lot of complexity, but due to the lack of management and returning, some accident problems, especially when cross-platform development.
SWT designers have taken a different way that they force developers to explicitly release the operating system-related objects in the program code. SWT is efficiently designed in the mind, so that specific operating system resources have become an opportunity to show efficient design rather than just to do. The system resource requirements (code) used by the SWT program release resources are recycled. These system resource requirements call the Dispose method to explicitly release.
In practice, the release of objects is a subtle thing, and when another object is trying to access an object entry that has been released, it will lead to unpredictable results.
Basic structure of a SWT program
As already said, a SWT program relies on the resources of the local platform (packaged by the Display class, we will see) in two aspects, allocated resources (such as color, images, etc.) and event processing mechanisms H. As for event processing, SWT only allows a thread to process local user interface events.
Now let's take a look at the basic structure of the SWT program. This helps us understand the basic architecture of SWT.
Two basic classes, Display, and Shell classes are used in any SWT program. An instance of the Display class is responsible for managing SWT and underlying operating systems, and enhances SWT models (such as enhancing color or images). The shell class depicts those windows managed by the platform-related desktop manager. Typically, a SWT program first establishes a local resource manager (an instance of a Display class) and connects all the needs of the window components (assigning 80x86). Listing 1 shows this typical mechanism: List 1: Display code snippet using Display and Shell class 00: Display Display = new display (); 01: shell shell = new shell (display); 02: // gui code here03: Shell.Open (); 04: while (! shell.isdisposed ()) {05: if (! Display.readandDispatch ()) 06: Display.sleep (); 07:} 08: Display.dispose (); 09: } 10:}
In order to fully understand the code of the list 1, you need to understand the ReadandDispatch method of the Display class. This method reads an event from the event queue of the operating system, and sends it appropriately (Dispatching). If you have additional events to be processed, this method returns true if you want to wait until another event is placed in an event queue. Listing 1 The circulation of the 4-9 rows is typical in the SWT program. It is responsible for advancing all underlying platform events into the SWT program (deal with) until the shell is released, and the post program will exit the event loop.
Basic control
Some basic components (such as Controls, them call this name) as follows: Button. This component is a famous button component used in toolbar, table, and more. ComboBox. This window component is a famous combo component. Label. This window component depicts an object used to display a string or image (cannot be selected). This window component depicts a basic list component. ProgressBar. It shows a progress bar. Sash. It is the equivalent of JSplitpane in swing. This window component can change the size of two regions in a GUI by stretching. Scale. (Ruler) This component implements an editable GUI project that displays a range of continuous values. Slider. This component depicts an editable object that represents a discrete numerical range. This component depicts a basic form. This component depicts a basic text area. This component depicts a basic tree window component. STYLEDTEXT. This component depicts a text area, this text area has font styles and other advanced properties.
SWT vs. swing
In this article, we compare these two technologies to make conclusions, that's better, when is it better?
Swing provides a lot of features, which provides a higher level of abstraction (this is very helpful when developing complex GUI using user components). Typically, SWT is easy to use at the beginning, but if complex GUI is established, Swing is usually easy to use and flexible. Table 1 shows the main components supported by three mainstream GUI libraries.
Table 1: Comparing visual componentsComponentSWTSwingAWTButtonXXXAdvanced ButtonXXLabelXXXListXXXProgress BarXXSashXXScaleXXSliderXXText AreaXXXAdvanced Text AreaXXTreeXXMenuXXTab FolderXXToolbarXXXSpinnerXXSpinnerXXTableXXXAdvanced TableXX
First, SWT looks easier than Swing because it enables developers from many complex issues (such as carefully made Swing class hierarchy, plugged in Look and Fell, Mode - View - Control Method, etc.). Anyway, a potential problem with SWT is the need for resource management. Swing (and AWT) Follow the Java model recycling in the automatic resource, released local resources in SWT requires programmers to explicitly complete. A clear release resource will become an retreat (also a cost) in the program debugging time, at least for a general Java developer. This is a harsh thing. This means that SWT programmers means more control (and more complicated) rather than the use of Swing is automatically controlled (and slow).
Although SWT supports local-independent depiction window components (like Swing), the default window component is based on local method Peers (like old AWT). In addition, most Eclipse Peers do not allow inheritance. (Obviously, if you are writing Eclipse plugins, don't choose from using SWT.)
Sitting in the back of the brief, whenever you want to closely combine with your local platform, SWT will be a favorable condition (option). Similarly, if you want to use the Java language, just want to use on the Windows system (or on several other supported platforms), SWT (also Eclipse platform) is better than Swing. However, you should carefully pay attention to learning to use the Hidden costs of the Eclipse IDE and SWT libraries. Moreover, SWT uses a clear release of resources, which is useful in some cases, but it is useless in other cases. If you don't want to develop cross-platform, and your target operating system also supports (such as Windows), you can consider using SWT, especially your customers use old-fashioned machines, those machine Swing's use is banned of. For additional situations, Swing provides a safe choice.
Conclusion and reference
In this article, we introduced SWT and compared with Swing. My purpose is to show the preliminary thinking of this library and his main features. We briefly compare SWT and SWING. Some of the resources available (selected from many resources) are listed below give those readers who are interested. Http://www.eclipse.org/- The home page of Eclipse Project. http://gcc.gnu.org/java/-gcj project home page. Http://www.java.sun.com/products/plugin/-sun Official website for Swing technology. Http://www-106.ibm.com/developerWorks/library/J-NATIVEGUI/-vogen, Kirk article "Create Native, Cross-Platform GUI Applications" website
About the author Mauro Marinilli is currently finishing his second book, on professional Java graphical user interfaces. Heteaches CS courses at the University of Rome 3 in Italy while being active as a consultant and as anacademic researcher in case-based reasoning, Human Computer Interaction and its Applications to e-Learning.you can email him at contact@marinilli.com.
Translator: 80x86 Jilin University School of Computer College LiUXin8312@163.com
Original text
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 Well 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. We will associate 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, with hiding it. for break, 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 Sophistated 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 Program 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. ........................ ..
In Practice, Disposing of Objects IS A DELICATE Business and It Can Lead to Unpredictable Results WHENEVER ANOBJECT 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). .
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;
02: // GUI Code Here
03: shell.open ();
04: While (! Shell.isdisposed ()) {
05: if (! Display.readDispatch ())
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. STYEDText. This Component Represents A Text Area with Styled Fonts and Other Advanced Attributes.
SWT vs. swing
We complude this article comparing these two technologies. Which is better, and when?
Swing provides a larger set of features, it is much more elegant, and gives an higher abstraction level (that turns helpful when developing complex GUIs with custom components). In general, SWT is easier to use at first, but when it comes to building complex GUIs, Swing usually results are easier to use and more flexible In Table 1, support for the main components is shown for the three main GUI libraries.Table 1:. Comparing visual componentsComponentSWTSwingAWTButtonXXXAdvanced ButtonXX LabelXXXListXXXProgress BarXX SashXX ScaleXX SliderXX Text AreaXXXAdvanced Text AreaXX TreeXX MenuXX Tab Folderxx ToolbarxxxSpinnerxx Spinnerxx Tablexxxadvanced Tablexx
At first, SWT may seem simpler to use than Swing because it spares developers from a lot of sophisticated issues (such as the elaborated Swing class hierarchy, pluggable look and feel, the Model-View-Controller approach, and so on). Anyway, one potential problem with SWT is in the need for resource management. Swing (and AWT) follows the Java paradigm of automatic resources disposal, while in SWT de-allocating native resources needs to be accomplished explicitly by the programmer. Explicitly de-allocating the resources could be a step back in development time (and costs) at least for the average Java developer. This is a mixed blessing. It means more control (and more complexity) for the SWT developer instead of more automation (and slowness) when using Swing .
Although SWT supports non-natively rendered widgets (similarly to Swing), the default widget implementations are based on native peers (similarly to the old AWT). In addition, most of the Eclipse peers do not allow for inheritance. (Obviously, if you 're writing Eclipse plugins, you have no choice but to use SWT.) Recapping, whenever one needs a tight integration with the native platform, SWT can be a plus. Similarly, if one wants to take advantage of the Java language but needs to deploy only on Windows (or some of the few other supported platforms), SWT (and the Eclipse platform) is a better choice than Swing. But, be careful about the hidden costs associated with learning to use the Eclipse IDE and the SWT library. Also, the explicit de-allocation mechanism adopted in SWT could be useful in some situations and uselessly complex in others. If you do not need cross-platform development and your target OS is supported (Windows, for example), you may consider SWT , especially if your cupom ERS Have Old, Limited Machines Where Swing Use Can Be Prohibitive. For All Other Scenarios, Swing Provides The Conservative Choice.
Conclusion and References
In this Article, We Introducted SWT and Compared It With Swing. My Intent Was To Give A First Idea of this Library and ITS Main Characteristics. We compcted Contrasting Briefly Swt Against Swing.
In The Following Are Listed Some (Among The Many) Resources Available for the INTERESTED READER.
http://www.eclipse.org/-the home point page of the eclipse project. http://www.java.sun. com / products / plugin / -The official Sun Web site about Swing technology. http://www-106.ibm.com/developerworks/library/j-nativegui/-The site for Vogen, Kirk's article "Create native, cross- Platform GUI Applications. "About the Author
Mauro Marinilli
is currently finishing his second book, on professional Java graphical user interfaces. He teaches CS courses at the University of Rome 3 in Italy while being active as a consultant and as an academic researcher in case-based reasoning, Human Computer Interaction and its applications to E-Learning. You Can Email Him At
Contact@marinilli.com.
