SOFA 2.0 repository editor v. 1.3.0 released. Changes »
SOFA 2.0 repository editor v. 1.0.149 released.
Work on the plug-in is started. History »
“ User's manual ”
“ Usage scenarios ”
“ UML diagrams ”
“ Java docs ”
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.
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.
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:
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.