SOFA 2.0 Editor - GUI Repository Designer for Eclipse

NEWS

2007-06-10

SOFA 2.0 repository editor v. 1.3.0 released. Changes »

2007-02-10

SOFA 2.0 repository editor v. 1.0.149 released.

2006-10-21

Work on the plug-in is started. History »

MANUALS

Compiling and installation

User's manual

Usage scenarios

Developer's manual

UML diagrams

Java docs

Author MaViNes (c)

ARTICLES

OSGI Framework

Eclipse plugin basics

RCP basics

SWT draw basics

jFace tips

SWT Linux/Windows differences

Author MaViNes (c)

<< Previous | Table of contents | Next >>

Chapter 4 SWT and jFace for GUI development

Standard Widget Toolkit (SWT) provides a platform-independent API tightly integrated with the operating system's native windowing environment. SWT's approach provides Java developers with a cross-platform API to implement solutions that "feel" like native desktop applications. This toolkit overcomes many of the design and implementation trade-offs that developers face when using the Java Abstract Window Toolkit (AWT) or Java Foundation Classes (JFC).

The JFace toolkit is a platform-independent user interface API that extends and interoperates with the SWT. This library provides a set of components and helper utilities that simplify many of the common tasks in developing SWT user interfaces. This toolkit includes many utility classes that extend SWT to provide data viewers, wizard and dialog components, text manipulation, and image and font components.

It were used several widgets and UI factories in the project. The very important here are UI elements like scrolled forms, sections, form toolkit factory, table and table layout.

Form Toolkit

The toolkit is responsible for creating SWT controls adapted to work in Eclipse forms. In addition to changing their presentation properties (fonts, colors etc.), various listeners are attached to make them behave correctly in the form context.

In addition to being the control factory, the toolkit is also responsible for painting flat borders for select controls, managing hyperlink groups and control colors.

The toolkit creates some of the most common controls used to populate Eclipse forms. Controls that must be created using their constructors, adapt() method is available to change its properties in the same way as with the supported toolkit controls.

Typically, one toolkit object is created per workbench part (for example, an editor or a form wizard). The toolkit is disposed when the part is disposed. To conserve resources, it is possible to create one color object for the entire plug-in and share it between several toolkits. The plug-in is responsible for disposing the colors (disposing the toolkit that uses shared color object will not dispose the colors).

FormToolkit is normally instantiated, but can also be sub classed if some of the methods need to be modified. In those cases, super must be called to preserve normal behavior.

We use the toolkit in the project almost everywhere in views. This is good way to create flat web-like look of forms.

Sections

One of the most versatile custom controls in Eclipse Forms (and seen in all PDE editors) is Section. It extends the expandable composite and introduces the following concepts:

  • Separator - a separator control can be created below the title
  • Description - an optional description can be added below the title (and below the separator, if present)
  • Title bar - a title bar that encloses the section can be painted behind the title (note that separator and title bar should not be used simultaneously)
The sections are widely used within the project. It is important to remember some notes about sections. Sections are not containers. It is required to create some composites over a section to place widgets on it. It is required to set the composite as a client for the section when the composite is prepared and all widgets are correctly placed on it. It is required to use layout with sections. Otherwise you will see nothing. Layout can not be omitted.

Scrolled form

ScrolledForm is a control that is capable of scrolling an instance of the Form class. It should be created in a parent that will allow it to use all the available area (for example, a shell, a view or an editor).

Children of the form should typically be created using FormToolkit to match the appearance and behavior. When creating children, use a form body as a parent by calling 'getBody()' on the form instance. Example:

  FormToolkit toolkit = new FormToolkit(parent.getDisplay());
  ScrolledForm form = toolkit.createScrolledForm(parent);
  form.setText("Sample form");
  form.getBody().setLayout(new GridLayout());
  toolkit.createButton(form.getBody(), "Checkbox", SWT.CHECK);

No layout manager has been set on the body. Clients are required to set the desired layout manager explicitly.

The main advantage of the scrolled composite is that it supports automatic reflow on content changed. The scrolled composite does not support this. It is required to implement appropriate listeners to listen when content is bigger than a scrolled area. That is why all scrolled composites in the project where changed to scrolled forms.



<< Previous | Table of contents | Next >>

Learn More