Eclipse Magazine

NEWS

COLUMNS

ONLINE ARTICLES

MAGAZINE

CONFERENCE

| Printer Friendly | Post Reply

Better Development: Comparison Test for Current SWT GUI Builders

By Peter Friese

Introduction

When Eclipse was released as an open source project in November 2001, it was presented as an Integrated Development Environment (IDE) platform with a Java IDE, which was already very promising. Over time, Eclipse has developed into a universal platform for everything possible. However, one particular aspect has remained – the Java Development Toolkit (JDT), which was originally intended only as an example, has not included any Graphical User Interface (GUI) designers from the beginning. Thus, anyone who wanted to develop GUIs has always had to rely on writing a lot of user interface code by hand — regardless of which GUI toolkit (AWT, Swing, or SWT) was used. It is interesting that the lack of GUI designers has repeatedly given rise to almost religious trench wars between the advocates of the various Java IDEs. Most Java Enterprise Edition (Java EE) developers have had only a smile left for such skirmishes; ultimately, mainly browser-based applications have been developed in recent years.

With the renaissance of Java Rich Clients (where the Eclipse Rich Client Platform accounts for a large percentage) in the enterprise environment as well, the call for good GUI design tools has become louder. Some manufacturers and individuals have been attempting to fill this gap in the meantime.

Note: The following GUI designer was not included in this review: V4All from Ramin Assis – a very popular plug-in. The author, however, has stopped further development owing to the availability of Eclipse Visual Editor [1] and SWT GUI Builder [2], a standalone GUI builder for SWT, which has not been developed further since the end of 2003.

The Test Suite

To create the same starting situation for all the tools presented here, each tool must be presented with certain tasks. First, a view should be designed for an imaginary plug-in, as shown in Figure 1. This task helps evaluate how tested programs handle simple layouts and how good the support for view actions is.

The next task consists of designing a dialog with title banner, as shown in Figure 2. This shows how simple it is to handle standard widgets and whether advanced dialog forms are already being displayed in the GUI Editor in a manner faithful to the original. The third exercise is to create a form editor, as shown in Figure 1. This shows whether, and how well, the Eclipse Forms API are supported.

Figure 1: Example Editor and View

Figure 2: Example Details Dialog

After these exercises, each tool must prove how well it handles existing GUIs. The Tasklist View and the dialog for configuring the task list filter have been used as test pieces for configuring the Tasklist Filter. To do so, the plug-in org.eclipse.ui.ide was imported into the workspace and the classes org.eclipse.ui.views.tasklist.TaskList and org.eclipse.ui.views.tasklist.FiltersDialog were opened with the respective GUI editor.

From hardcore developers in particular, one often hears statements such as, “I write my GUI by hand. GUI editors do not produce good code.” Good code is important, especially from the standpoint of subsequent maintenance of a software package. The tools investigated here, therefore, are also measured in this discipline. So, in addition to comprehensibility and good form of the code generated, we must also evaluate whether and how much one can have an influence on code generation.

With increasing complexity of a dialog, the size of the method createPartControl() also increases. Large methods can be simplified efficiently by repeated use of the refactoring Extract Method. Whether the GUI editor can then still depict the GUI properly will depend on the quality of the code parser and thus must also be tested. As the test case, we will swap out two columns from the view in Figure 1 into a suitable method for each.

One aspect that should not be disregarded in the implementation of Java GUIs is the choice of correct layout manager. Through corresponding programming, a platform independence of the GUI designs may thus be achieved. Especially in this area, a GUI designer can save the developer a great deal of time and nervous energy or expense. This point must be taken into account in selecting a GUI editor.

Eclipse Visual Editor

Visual Editor (VE), just like the Web Standards Toolkit, is derived from the commercial WebSphere Application Developer (WSAD). IBM has recognized that by publishing the source code and including the developer community, not only can more direct feedback to the original tools be obtained, but it is also less expensive to develop because the development cost is [ultimately] shared with other companies. VE first appeared in WSAD 5.0, but this version supported only Abstract Window Toolkit (AWT) and Swing. Support for Standard Widget Toolkit (SWT) was developed only after the tool was published under the umbrella of the Eclipse Foundation.

The installation runs without a problem and follows the scheme known for other plug-ins—install in the Eclipse directory so that everything can begin. However, VE has dependencies with Graphical Editor Framework (GEF) and Eclipse Modeling Framework (EMF); so the runtimes of these two components must be known or must be installed. (All components together require only 13 MB disk space.)

GUIs are created and processed in VE in a WYSIWYG editor. The source code belonging to the GUI is opened in the Java Editor below the WYSIWYG view and can be processed there. Anyone who would rather reserve the complete editor area for the WYSIWYG view and/or the Code Editor can configure the view as a Tabbed Editor in Preferences. The WYSIWYG Editor contains a component palette on which the available SWT widgets can be selected. The structure of a GUI is shown by VE in the Beans View and properties of the individual GUI elements can be processed in the Properties View. It is interesting that the events assigned to a widget are not displayed in Properties View (as is customary with many other GUI editors), but instead as child nodes of the corresponding widget in the Beans View. What is advantageous about this display is that an overview of the events of a GUI is obtained rapidly.

WYSIWYG view and Code Editor are synchronized, so that changes in code are immediately visualized in the WYSIWYG view and vice versa. This also functions very well in practice, but the parser is not the fastest. There is a ‘pause’ button that stops the parser and starts it again later. Unfortunately, the parser can be destabilized very quickly by simple refactorings. For example, if the code for generating a table column is extracted, then the column is no longer displayed. However, in VE the createPartControl() method has not become large due to the fact that VE already puts the GUI code for containers (for example, Composite, Group, and TabFolder) in separate methods. The code is thus organized so it is component-oriented, which facilitates an overview. Fortunately, VE also considers the code templates defined in JDT in code generation, so it is possible to call this very good code.

The design of GUIs that use SWT core components such as button, label, text, and tables is not a problem and proceeds easily. However, the remaining test suite presented some insurmountable obstacles for VE; generating JFace viewers proved to be problematical, for instance. There is no native support here so one must first generate the widget to be encapsulated by the viewer, and then [manually] design the corresponding viewer in the source code. One must also write content and/or label provider by hand, which is not so tragic in the final effect, but it would be helpful especially for those just entering the field if JFace support were further expanded. It is also impossible to generate a dialog derived from TitleAreaDialog — dialogs must be derived directly from Shell in VE. The same thing is also true of the Eclipse forms API that is also not supported in version 1.1 of VE. Support for Forms and JFace dialogs is planned for version 1.2 [3, 4, 5]. Although the developers of VE have invested a great deal of effort in the development of their code parser and have set themselves the goal of supporting as many code styles as possible, VE cannot display the two views characteristic of Eclipse.

Figure 3: Eclipse Visual Editor

Anyone who wants to tie custom components into VE can do this without any major problems. All the GUI elements derived from composite can be selected by Choose Bean and placed in the GUI editor. More work is required if these components should also appear in the palette [6].

Work with the various layout managers is supported very well in VE. If a new control element is selected and the cursor is placed over an area managed by a layout manager, the future insertion position is emphasized by an insertion bar. Alignment within the layout cells can also be controlled elegantly with the Layout Window.

SWT Designer

The product—SWT Designer—comes from the company Instantiations, which many should be aware of from the Visual Age days. This is a member of a product family that comprises Swing Designer [7], SWT Designer [8], and WindowBuilder Pro [9]. As the names indicate, GUIs for the particular GUI toolkits can be created with the designer variants. Window Builder includes the functionality of the two designer variants. All products are available on the basis of a commercial license (with the possibility of a maintenance contract) and in a limited free variant. Which functions the user can use will be determined by the influence of a license — the binaries are the same for all members of the product family. The installation goes as smoothly as with most other plug-ins. The plug-in is downloaded as a zip file that is unzipped into the Eclipse directory — and you’re done. Instantiations seemingly holds its own tool to be so self-explanatory that help is offered only as a separate download. After installation, SWT Designer occupies slightly more than 8 MB memory with about 9 MB extra for help. Just like Eclipse VE, SWT Designer is based on GEF, but the correct version of GEF (and all other required libraries) is contained in the ZIP file and is installed automatically. After restarting the IDE, a license must also be agreed to; this may be done directly from the Preferences dialog of SWT Designer.

Designing GUIs manually proceeds quite smoothly with SWT Designer’s intuitive operation. New user interface elements (that is, dialogs, views, and editors) can be set up with the help of a wizard. Processing the GUI takes place in a combined WYSIWIG/code editor. The property editor and the component palette are situated to the right and left, respectively, of the WYSIWIG view, as shown in Figure 4. The appearance of the editor may be adjusted to a great extent; for example, the source code view may be depicted on a separate tab or side-by-side with the WYSIWIG view. The WYSIWYG view and the Java Editor are coupled as a two-way tool. The two views were always synchronized in the tests, at any rate with self-generated classes.

Figure 4: SWT Designer

SWT Designer passed the test suite without any problems—views, dialogs and editors could be generated and processed in a truly elegant manner, all SWT components are supported. The good support for JFace should be mentioned in particular. All JFace viewers are available as independent components in a separate heading on the component palette and can be placed on the GUI by ‘Drag and Drop’. Content and label provider can be generated by double-clicking on the corresponding property in the property editor. There is a separate page in the GUI editor for processing actions, which facilitates the processing of views.

Forms API [10,11] is also supported, so that nothing stands in the way of creating GUIs based on this new technology. Displaying GUI code created manually or with another tool always poses considerable problems for GUI editors. Although the Code Parser of SWT Designer does work well, it is at its performance limit with foreign code. It can only depict a rudimentary task list viewer, and an attempt to open the Tasklist Filter Dialog ended with an internal parser error.

In GUI code refactoring, one can again go a relatively great distance; swapping out the production of individual GUI blocks does not touch on the depiction of the GUI entirely as desired. In contrast with VE, the code is unfortunately not organized according to components from the beginning; so one must often rely on refactoring. Otherwise the code generator can be adjusted in a detailed manner, and prefixes and suffixes for the individual components can also be defined. In addition, it is possible to determine for each type of component whether a field or a local variable should be used to generate the widget.

As a particular feature, SWT Designer supports so-called templates—but anyone who suspects, for example, composite components behind this would be wrong. This is only about the possibility of defining the new standard values for the properties of individual widget classes. This can be practical if many similarly formatted GUI elements are to be inserted in succession. Another interesting special feature is to support a visual inheritance; SWT Designer represents all GUI elements of the respective superclasses for subclasses of Component as well as of Shell. This feature can be utilized to quickly develop one's own graphic components. A text input field with a label should therefore be implemented within a few minutes. Such self-developed components may be added to the component palette via the Preferences dialog so that a repository of these components can be built up easily.

SWT Designer includes good support for SWT Layout Manager—the insertion position is emphasized graphically and there is a layout assistant, as in VE, which helps in the alignment and extension of individual components during configuration.

Jigloo

Jigloo from Cloudgarden is the most frugal of all the plug-ins presented here, at least with regard to memory demand on the hard drive. After a simple installation (unzipping, and you’re done), the Eclipse directory has increased by approx. 2.3 MB. Online help is also installed at the same time but is not very useful. For non-commercial use, Jigloo is free and can be used without restrictions on function; commercial licenses are available for USD 75.

Figure 5: Jigloo

As with the two other tools, new visual classes are created with the help of a wizard. Unfortunately, the wizard does not offer all possible visual classes, so this situation must be remedied manually. The GUI editor itself may be displayed either in split-pane mode or as a ‘Tabbed Pane’. One-half of the ‘window’ relies on Java Editor while the other half uses the GUI editor. One type of component palette shows the available components at the upper edge of the screen. To process the component properties, a view is inserted at the lower edge of the screen. The view shows the properties and events of a component on separate riders. Alternatively, the different categories may be depicted side-by-side. At first, this form of display takes some practice, but it has also proven to be very practical—especially in the case of components having many properties.

Simple UIs can be created easily with Jigloo, but it is tedious and complex to create complicated layouts because there is no layout assistant and all layout properties must be adjusted manually via the GUI Properties View. SWT layout managers are supported; however, handling insertion of new components is not as elegant in VE and SWT Designer. Unfortunately, as a result, components must be inserted directly in the proper order (display order) or be inserted into the proper position subsequently using the mouse.

At best, support for JFace is rudimentary. Although the central JFace viewers are offered on an extra page of the component palette, there is no support for label and/or content providers. Further, it is not possible to address the internal components of a viewer. The creation of JFace based GUIs is possible only with additional manual work, which unnecessarily inhibits work.

On the whole, there is the impression that Jigloo has weaknesses in the area of more modern GUIs. For example, there is no support for Eclipse Forms API. However, JFace dialogs can be written and processed in principle. Thanks to visual inheritance, it is also possible to create composites with Jigloo with no problems. Of all the tools presented here, Jigloo offers the best support for incorporation of self-written components in the component palette. The components palette can be freely configured via the Preferences dialog and any components derived from the composite can be added. Jigloo cannot display Eclipse dialogs belonging to the test suite (Tasklist View and Tasklist Filter Dialog) well, although the code parser can even be configured via Window>Preferences>Jigloo.

The Parser empowers simple refactorings of GUI code so that nothing stands in the way of proper organization of the code. Although there are various options for configuration of the code generator, they do not have any visible influence on the code generated. As is the case with SWT Designer, Jigloo writes the complete GUI code first to a major method (createPartControl() and/or open()); you must thus logically organize your code through suitable refactorings subsequently. See Figure 6.

Figure 6: Test Results

Conclusion

Of all the products tested, SWT Designer gives the impression of being the most fully refined. VE gives a stable impression in the SWT range but the lack of support for JFace and Eclipse forms is difficult to justify. VE must be given credit for the fact that the origin of Tools is in the Swing area and SWT support has been in existence for only a few months. Furthermore, VE is the only product that can be used as the basis for one’s own GUI designer — not only on the basis of the license form (Open Source Eclipse EPL), but also because it is the only tool providing access to the required extension points. The tutorial, ‘Extending the Visual Editor Tutorial: Enabling Support for a Custom Widget’ [12], explains how simple components are integrated into VE while in the tutorial, ‘Extend VE to Build a ULC GUI Builder’ [13], the authors describe in detail how an independent GUI editor has arisen for a proprietary application framework on the basis of VE.

The creation of GUIs can be accomplished with all three comparable tools well and more productively than by the tedious coding of GUIs by hand. However, this is true only of standard SWT GUIs; as soon as the modern GUI variants are created (JFace, Eclipse Forms), only SWT Designer will meet the need.

Resources & References

[1] Visual Editor Project

[2] SWT GUI Builder

[3] Eclipse Bug #64039

[4] Eclipse Bug #100145

[5] Eclipse VE Newsgroup

[6] Gili Mendel et al: Extending the Visual Editor Tutorial: Enabling Support for a Custom Widget:

[7] Swing Designer

[8] SWT Designer

[9] WindowBuilder Pro

http://www.eclipse.org/vep/WebContent/docs/VEpapers/ulc.pdf

[11] Jim D’Anjou u.a.: Eclipse Forms Programming Guide

[13] Extending the Visual Editor Tutorial: Enabling Support for a Custom Widget:

[12] Dejan Glozic: Eclipse Forms: Rich UI for the Rich Client

Yatego Shopping with more than 4000 Shops and with over 1.8 Mio Products. Branchenbuch and over 500.000 Bücher. Inspiration with Themeworld and Technic. A mobilephone- and Handy Shop with Nokia Handy, Motorola Handy and Sony Handy. With our Bestseller easily find Schuhe, Jeans, Kinderschuhe or a Digitalkamera, perhaps a Canon Digitalkamera. More Bestseller: Modellbahn, Diddl and Poker. Find Schmuck or Silberschmuck as easy as an Apple Ipod, Weber Grill or an Akkuschrauber.

About Us | Advertise | Contact | Feedback | Publisher