[news.eclipse.tools] Summary of Swing Interoperability

["Greg Adams" <greg_adams@xxxxxxx>]

There have been several questions posted regarding Swing interoperability
with the Eclipse platform.
I thought I would try and address these questions and provide some
additional information on tool integration.

First, let me recap the mechanisms for tool UI integration. They are:
#1
In-Place-Java-Tools coded using the ISV Kit Workbench's API's and JFace/SWT.
These tools run in the same VM and same class libraries as the Workbench
itself and can leverage the full ISV integration API for seamless
integration. These tools open in-place in the Workbench and contribute views
or editors into the Workbench's perspectives. Note that an
In-Place-Java-Tool can be entirely coded in Java, but can also make use of
an ActiveX control itself (on the Windows platform only).

#2
Launch-Java-Tools coded in Java, using Swing or AWT.  These tools run in the
same VM and the same class libraries as the Workbench itself, but are
otherwise loosely coupled and operate in much the same manner as
External-Launch-Tools. This mechanism allows swing-in-process tools to be
opened as separate windows (not in place).

#3
External-Launch-Tools, coded in any language, that are launched as external
programs. These tools open as separate windows and are  not visually
integrated into the workbench. The platform provides automatic launching of
external editors based on file type associations provided to the Workbench
or obtained from the
underlying operating system.

#4
In-Place-OLE-Documents (Windows platform only) allow standard OLE enabled
tools that support in-place OLE documents (such as MSWord, MS Powerpoint,
etc) to be invoked in place in the Workbench to edit artifacts of the
corresponding type. These tools are otherwise loosely integrated, and
functionally they are the same as External-Launch tools i.e. they open on an
artifact, edit it, save it.


What about swing-in-place?
Recent Eclipse drops have included an experimental 5th mechanism which
provides rudimentary swing-in-place -- that is, in-place-Java-tools coded in
Swing or AWT using the SWT_AWT widget.  These experimental mechanisms do not
fully work on windows, and may result in a number of problems (text field
misbehavior, possible deadlock cases). Moreover, the swing-in-place does not
work (at all) on other platforms.

Where are the swing-in-place experimental mechanisms in drop 046?
As of build 046 these experimental mechanisms have been moved into the
package com.ibm.swt.internal.win32.awt.  As the package name implies, these
mechanisms are internal, platform specific and experimental. If you want to
"experiment" with swing-in place you can do so using this "as-is" package.
However,  it is important keep in mind that internal packages (including
this one) are subject to change and could be removed in future. More
generally any packages not identified in the javadoc as API are internal.

What if I have existing swing code?
The Eclipse platform is intend to foster the seamless integration of tightly
coupled tools following a similar look/feel and behavior thereby promoting a
consistent experience for users on all platforms.  Clients targeting Eclipse
integration should use SWT based tools to ensure both tight seamless
integration and portability.  Clients with swing based components who cannot
immediately take advantage of all aspects of the Eclipse platform should in
most cases use mechanism #3 above (launch-tools yielding swing-in-process)
as a stepping stone towards ultimately achieving tighter tool integration.
The experimental internal mechanism for swing-in-place is discouraged, and
should be used only after considering the risks and limitations as indicated
above.

/Greg
Eclipse Platform Team