|
Building the European Network For Lifelong Competence
Development TENCompetence IST-2005-027087 |
Project Deliverable Report |
SWT
Editor |
Workpackage |
WP3 |
|||
Task |
C8 |
|||
Date of delivery |
|
|||
Code name |
|
|||
Type of deliverable |
|
|||
Security (distribution level) |
|
|||
Contributors |
|
|||
Authors (Partner) |
Carlos
Méndez Pérez (Altran) |
|||
Contact Person |
|
|||
WP/Task responsible |
Ruud
Lemmers |
|||
EC Project Officer |
|
|||
Abstract |
|
|||
Keywords List |
Editor,
Eclipse, Plugin, HTML, WYSIWYG |
TENCompetence Project
Coordination at: Open University of the Valkenburgerweg 177, 6419 AT Tel: +31 45 5762624 – Fax: +31 45
5762800 |
Frame background color in Firefox
Portability and platform integration
Inside TENCompetence initiative
exists the need to edit documents using a Rich Text format to allow the use of
tables, fonts, colors, hyperlinks, images…
For TENCompetence frameworks
exists two different parts. From the server side exists an implementation of
the TENCompetence framework to control all the aspects of the initiative. From
the Client side, a desktop client is being developed to manage from a ‘User
Friendly’ software all the features of the server.
To create contents directly from
the Desktop Client this software must have the capability of edit the
description and content of several items in the system, like Resources,
Activities, Programmes…
To allow this feature, a rich-text
editor has been created, easy to integrate with the Desktop Client of TENCompetence,
allowing to edit every content using its features.
The edition of contents uses HTML language But for a user of the system
is not necessary to know this language. The user directly select the different
features of the editor: font, colour, table, images to be included in his/her
document and the editor generates the proper code in formal HTML language
By the other hand a project is opened in www.sourceforge.net to manage resources,
access news, documentation and availability of the latest releases of the
editor in http://swteditor.sourceforge.net/.
To install the
plugin into the Eclipse IDE the file of the editor must be placed on the plugins directory. Once restarted the
IDE, it’s possible to see if the editor is correctly installed check the plugin
in Help > About Eclipse SDK >
Plugin Details
Actually some of the
functionalities of the editor are disabled for technical issues regarding
compatibility. By the other hand, the editor can work in, at least, Windows,
MacOSX,GNU/Linux, OpenBSD… The main requirement is the need of an
implementation of the Java Virtual Machine for this operating system. Another
requirement is to have a browser installed in the system. This requirement is
not necessary to take account in Windows because Internet Explorer is embedded
inside. But in another OS, specially *Nix is important. That’s because the SWT
browser widget uses the default browser engine to show HTML documents. In
windows there’s no choce, the browser always uses Internet Explorer.
For the moment this plug-in has been tested
with Internet Explorer and Firefox (Gecko).
To open the editor go to Window > Open Perspective > Other > HTML Editor. Or Window > Show View > HTML Edition > HTML Editor
Actually the editor supports:
· Load HTML documents
· Font Color
· Bold
· Italic
· Underline
· Strike Through
· Subscript/Superscript
· Center/Left/Right/Justify Full
· Indents/Outdents
· Hyperlinks
· Tables
· Horizontal Rule
· Ordered/Unordered Lists
· Show HTML code
Actually table features are
developed. Tables always are inserted at the end of the document. It’s possible
to move the table to the desired place.
Actually image features are
developed. For the moment only external links to images are available. Images
always are inserted at the end of the document. It’s possible to move the table
to the desired place.
For the moment no font selection are
abailable.
In this release is not possible to
select the size of the font.
The background color is white, for
the moment is not possible to change it.
For save the documents directly from the editor to another place is not possible to do directly from the browser. That’s because don’t exists a method to extract the content of the browser. For the moment Save Document are disable. It’s possible to save documents doing a HTTP Post to another place.
To create text documents in the different resources of
the TENCompetence Enviroment the HTML language is used. In order to avoid that
a user must publish this document having a knowledge of the language HTML, a
text editor WYSIWYG(What You See
Is What You Get) has been created to generate that code automatically.
An user can use the functionality of the editor inside
the TENCompetence client to create rich text documents with tables, images,
different fronts, colours, hiperlinks…
One of the most important requirements is the
possibility of being used in different operating systems, allowing the user to
chose.
The editor has been created in JAVA using SWT(See Annex 1) to be able to integrate as a plug-in of
Eclipse. It can be integrated also with the client of TENCOMPETENCE as a plug-in.
In this way it is possible to be created like an independent product to publish HTML documents using eclipse.
Developers can use the product inside the IDE or can be integrated in another
third party applications to increase the functionality.
For manage the look-alike of the editor 2 extension
points are defined, a perspective and a view. In the view it’s define of how
the editor can be showed (position, size…). By the other hand, a perspective
can group views.
Using the functionality of JavaScript to control the
properties of the DOM objects it’s possible to control HTML documents directly
with this language. In this case, to be integrated as a plugin, JavaScript is
integrated inside the product using an API to communicate with. In this way
it’s possible to control the different HTML elements using JAVA classes.
To show a WYSIWYG editor a web browser widget is used. The commands to execute are called in
Java, there fore the API translates to JavaScript and the command gets executed
in the browser.
The
Standard Widget Toolkit (SWT) is a widget toolkit for Java developers that
provides a portable API and tight integration with the underlying native OS GUI
platform.
Many
low level UI programming tasks are handled in higher layers of the Eclipse
platform. For example, JFace viewers and actions provide implementations for
the common interactions between applications and widgets. However, knowledge of
SWT is important for understanding how the rest of the platform works.
SWT
defines a common portable API that is provided on all supported platforms, and
implements the API on each platform using native widgets wherever possible.
This allows the toolkit to immediately reflect any changes in the underlying OS
GUI look and feel while maintaining a consistent programming model on all platforms.
SWT
includes many rich features, but a basic knowledge of the system's core - widgets,
layouts, and events - is all that is needed to implement
useful and robust applications.
When
you are contributing UI elements using platform workbench extensions, the
mechanics of starting up SWT are handled for you by the workbench.
If
you are writing an SWT application from scratch outside of the workbench, you
must understand more about SWT's application structure.
A
typical stand-alone SWT application has the following structure:
· Create a Display which represents an SWT session.
· Create one or more Shells which serve as the main window(s) for the application.
· Create any other widgets that are needed inside the shell.
· Initialize the sizes and other necessary state for the widgets. Register listeners for widget events that need to be handled.
· Open the shell window.
· Run the event dispatching loop until an exit condition occurs, which is typically when the main shell window is closed by the user.
· Dispose the display.
The
following code snippet is adapted from the org.eclipse.swt.examples.helloworld.HelloWorld2 application. Since the application
only displays the string "Hello World," it does not need to register
for any widget events.
public static void main (String [] args) {
Display display = new Display ();
Shell shell = new Shell (display);
Label label = new Label (shell, SWT.CENTER);
label.setText ("Hello_world");
label.setBounds (shell.getClientArea ());
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}
The
Display represents the connection between SWT
and the underlying platform's GUI system. Displays are primarily used to manage
the platform event loop and control communication between the UI thread and
other threads. (See Threading issues for clients for a complete discussion of UI
threading issues.)
For
most applications you can follow the pattern that is used above. You must
create a display before creating any windows, and you must dispose of the
display when your shell is closed. You don't need to think about the display
much more unless you are designing a multi-threaded application.
A
Shell is a "window" managed by
the OS platform window manager. Top level shells are those that are created as
a child of the display. These windows are the windows that users move, resize,
minimize, and maximize while using the application. Secondary shells are those
that are created as a child of another shell. These windows are typically used
as dialog windows or other transient windows that only exist in the context of
another window.
All
widgets that are not top level shells must have a parent. Top level shells do
not have a parent, but they are created in association with a particular Display. You can access this display using getDisplay().
All other widgets are created as descendants (direct or indirect) of top level
shells.
Composite widgets are widgets that can have
children.
When
you see an application window, you can think of it as a widget tree, or
hierarchy, whose root is the shell. Depending on the complexity of the
application, there may be a single child of the shell, several children, or
nested layers of composites with children.
Some
widget properties must be set at the time a widget is created and cannot be
subsequently changed. For example, a list may be single or multi-selection, and
may or may not have scroll bars.
These
properties, called styles, are set in the constructor. All widget
constructors take an int argument that specifies the bitwise OR
of all desired styles. In some cases, a particular style is considered a hint,
which means that it may not be available on all platforms, but will be
gracefully ignored on platforms that do not support it.
The
style constants are located in the SWT class as public static fields. A
list of applicable constants for each widget class is contained in the API
Reference for SWT.
The
platforms underneath SWT require explicit allocation and freeing of OS
resources. In keeping with the SWT design philosophy of reflecting the platform
application structure in the widget toolkit, SWT requires that you explicitly
free any OS resources that you have allocated. In SWT, the Widget.dispose()
method is used to free resources associated with a particular toolkit object.
The
rule of thumb is that if you create the object, you must dispose of it. Here
are some specific ground rules that further explain this philosophy:
· If you create a graphic object or widget using a constructor, you must explicitely dispose of it when you are finished using it.
· When a Composite, is disposed, the composite and all of its child widgets are recursively disposed. In this case, you do not need to dispose of the widgets themselves. However, you must free any graphics resources allocated in conjunction with those widgets.
· If you get a graphic object or widget without using a constructor (e.g. Control.getBackground()), do not dispose of it since you did not allocate it.
· If you pass a reference to your widget or graphic object to another object, you must take care not to dispose of it while it is still being used. (Similar to the rule described in Plug-in patterns for using images.)
· If you create a graphic object for use during the lifetime of one of your widgets, you must dispose of the graphic object when the widget is disposed. This can be done by registering a dispose listener for your widget and freeing the graphic object when the dispose event is received.
There
is one exception to these rules. Simple data objects, such as Rectangle and Point, do not use operating system
resources. They do not have a dispose() method and you do not
have to free them. If in doubt, check the javadoc for a particular class.
See
Managing operating resources for further discussion of this
topic.