Introduction to the beautiful UI of Eclipse forms design

Design This article will show you how to add Eclipse Forms to your rich client program. Eclipse forms can achieve web effects without embedding browsers in your program. This will not only maintain complete control over the components but also all the portability of eclipse, this article guides you step-by-step from the basic features of Eclipse forms to advanced features.

　　 History

The basic features of an eclipse platform are: All of the program interfaces developed on the Eclipse platform can be like local programs. Because SWT, menus, windows, trees, tables, buttons, and other components are consistent with the system style on any operating system. As one of the earliest members of the Eclipse team, I remember the happy days of developing the Eclipse prototype code. The menu is real, work Toolbars are true, check menus, text boxes, buttons, check boxes, radio buttons are true. They are not drawn, they are the local components of the operating system that is invoked.

For a long time, if you've written Eclipse Plug-ins, they're basically in the following range:

1.Editors (editor)

2.Views (view)

3.Wizards (Wizard)

4.Dialog (window)

This scope has clear rules on how to write Plug-ins. We've seen the views of trees, tables, editors documents, and simple buttons and text boxes like wizards and Windows.

rcp in Eclipse 3.x extends a new set of features on the system, which brings a number of problem-effective solutions, and you can now build an entirely different RCP program on eclipse than the IDE.

Although General Workbench sections such as views and editors work well, the components that make up these parts (trees, tables, text editors, and so on) may sometimes not be the best solution in RCP. From Eclipse 3.0, Eclipse forms is designed to provide alternative solutions.

Ironically, the eclipse forms we developed solve an eclipse that existed long before the RCP An issue in the SDK. PDE developers who use specially edited plugin.xml with parsing, color-displayed text editors are not happy. There is nothing wrong with the Java editor for Eclipse, which is very powerful and ideal for this task. However, it is used to edit Java code, in the plug-in manifests, XML is used to abstract describe the data structure at a higher level. By editing XML manually, even with a syntax-parsing, color-display editor, most users find it inappropriate. In plug-in manifests, grammar is not the focus, the specific data and its meaning is the focus.

A good example of this is the use of HTML recognition tools to view tags. From the point of view of the code, we can see clearly the elements that contain the related attributes. Although we see grammar, it's hard to see what it's really about. A WYSIWYG view can display tables, colors, and some text content that contains tables, pictures, and so on. In this angle makes More productivity with HTML files.

Because the grammar and the tags are hidden in the background.

Figuring out the WYSIWYG concept for HTML documents is simple, because HTML tags are used to show the structure of a text document for a browser to represent attributes, hyperlinks, and pictures, WYSIWYG means editing a document in its final form-nearly as it would be in a browser. It is difficult to point out the appearance of an edit plug-in with a different method manifest editor. The final working group made the following decisions:

1. Show each part of the manifest in the most appropriate way. For example, important information such as plug-in name, provider, and so on, can be edited simply by a text box, and the hierarchical data structure, like the extension point definition, is displayed through the tree.
2. Each individual editing page is used to show the parts of the manifest, in the order in which they were originally in the Code.

3. Each page of the editor should maintain the style of the document and be able to accommodate different components, hyperlinks, pictures, text, and provide a scroll bar for too much of the page size content.


Picture 1:eclipse SDK1.0 The plugin manifest editor. It accommodates SWT components, hyperlinks, and pictures, and can be scrolled when there is not enough size (like a Web browser). Note that all components are smooth (flat) in order to appear more integrated with text content.
The 3rd effectively prompted it to be produced as a plug-in now named eclipse forms. After 1.0, other developers want to replicate the rich client interface of the PDE multi-page editor.

It was eventually released as a plug-in with a public API in Eclipse3.0.

In the following articles, we will show you what eclipse forms (and what is not eclipse forms) and how to use them simply to create a beautiful interface.

　　 Eclipse Forms Mission

Eclipse forms is an optional rich-client plug-in that provides a portable web-style user interface that is based on SWT and jface across all of the eclipse UI.

Eclipse forms breaks the pattern that can only be used for a specific Eclipse UI (editor, View, Wizard, window). To meet the needs of the developer, an eclipse form can appear as any UI. UI developers can use the most appropriate concepts for their tasks.

Eclipse is not designed to completely replace SWT or jface. This plugin has only a few carefully selected proprietary custom components, layouts, and support classes to achieve the desired results with SWT and jface.

Obviously, an Eclipse form usually looks like a Web page. The fact is that the form's program is all aspects of the feasibility of making forms powerful and appealing. The need for DOM support to achieve this flexibility with the browser is often almost decoupled. Eclipse Forms are portable and are written on SWT and JFace.

Eclipse forms has been overridden in 3.0 release to rely only on platform UI Plug-ins, not on Pde UI Plug-ins. Although they are not the least part of RCP, you can add Eclipse Forms to any RCP program.

The essentials cannot be underestimated. When you build eclipse forms, you are using SWT. There is no Eclipse forms button, there is no Eclipse forms tree component, and so on. You just use eclipse forms to get the existing components to a rich customer experience.

Eclipse forms is achieved through the following elements:

"Form" concepts and views, editors, etc. are a hierarchy of concepts.

A Toolkit (toolkit) to manage colors, and there are other aspects to the hyperlink group. and acts as a factory class for many SWT components.

A new layout manager manages the layout, similar to HTML tables.

A set of custom components to work with form. (Hyperlinks, picture hyperlinks, rolling combinations <scrollable composite>, Segments <section>)

An individual page is a multiple page editor for forms (e.g. PDE manifest editor)

Although Eclipse There is nothing in the design of forms that prevents you from creating a form in a single window. But most of the time, forms are used in views and editors, not windows or wizards. Indeed, adding a form to a regular window or wizard is a bit odd, after all, the other parts are common SWT components. Anyhow, in the future, it was a Explore the direction.

　　 Baby Steps

Using eclipse forms in your user interface is simple. Before you begin, you add the Org.eclipse.ui.forms plugin to the plugin dependencies section. We'll create a

Eclipse view and populate it with content. Note that all the code for this article plugin is available in the zip file format.

Hello, Eclipse Forms

We start the game by adding a blank form to the view:

public class FormView extends Viewpart {
Private Formtoolkit Toolkit;
Private Scrolledform form;

/**
* The constructor.
*/
Public FormView () {}

/**
* This is a callback that would allow us to create the viewer and
* Initialize it.
*/
public void Createpartcontrol (composite parent) {
Toolkit = new Formtoolkit (Parent.getdisplay ());
Form = Toolkit.createscrolledform (parent);
Form.settext ("Hello, Eclipse Forms");
}

/**
* Passing the focus request to the form.
*/
public void SetFocus () {
Form.setfocus ();
}

/**
* Disposes the Toolkit
*/
public void Dispose () {
Toolkit.dispose ();
Super.dispose ();
}
}
As you can see in this code, you don't need too much to create a form. We started by creating a Toolkit instance (). We create a form that scrolls by using Toolkit to provide composite as parent. We set the title of the form. And we're sure to pass the focus to form when we need it, when view Dispose toolkit also dispose of the case.

This view should look like this:


Picture 2
An empty form in the view narrows the view so that the form title is wrapped, and once there is no space to accommodate the entire form, the scroll bar is displayed.

Notice that we used a scrollable form, Because we put it in a view that can be resized. In more complex environments, such as a form that needs to be part of a layout, a form with no scrolling capability can be used. In this case, we'll call Formtoolkit.createform (), Let the outer parent solve the problem of needing a scroll bar.