In today's computing environments, it is important to deliver user interfaces that can run on a wide variety of platforms. The range is broad, encompassing small handheld devices as well as server consoles. When users interact with applications in the window-management environments with which the are most familiar, using the application must feel natural and predictable.

When you build a desktop application you need to start with good design and architecture. Since there is no universally accepted desktop application framework, most developers design their own architecture and then build it into a framework themselves. That approach, however, consumes considerable expense, time, debug effort, support and aggravation to solve a problem that is peripheral to building the business functionality of the application.

A much better approach than "rolling your own" application framework would be to find one that could accommodate your needs to simplify and accelerate project development.

Eclipse provides the framework for combining disparate tools into a single integrated application with a seamless user interface. New tools are integrated into the Eclipse Platform and its user interface through plug-ins that extend Eclipse's facilities and provide new functionality. Additionally, Eclipse plug-ins can extend other plug-ins. When an Eclipse-based application initializes, it discovers and activates all the plug-ins that have been configured for the workstation. The Eclipse platform is quite literally the sum of its parts since it is capable of performing any function that has been added to it by the plug-ins it currently contains.

Since being able to write and test such plug-ins is essential to the success of Eclipse, the Eclipse platform is bundled with a plug-in development environment and a set of Java development tools (JDT) to support it. The Eclipse developers clearly trusted the power of the frameworks they created. The entire development environment is just another set of tools integrated into the platform using the standard plug-in techniques. The Eclipse platform was itself created by developers using the Eclipse-based Java integrated development environment (IDE), initially in beta form. Since the platform is open-source, you can inspect the code and understand in great detail exactly how the frameworks are used.

It is this practice of packaging the development tools with the platform that causes some to be confused about the nature of Eclipse. The Java development tool components are so effective that they're attractive to all Java developers, not just those writing plug-ins. On the surface, Eclipse appears to be just an excellent Java IDE. But instead of thinking about Eclipse simply as a Java IDE, try to think about it as a desktop application that happens to include a Java IDE, which was built using the underlying Eclipse platform as an application framework.

As an IDE "for anything and nothing in particular," Eclipse embodies an extensible design that maximizes its flexibility as an IDE platform. Nonetheless, the Eclipse architecture defines sets of layered subsystems that allow it to be used as a framework for a portable desktop application (or suite) that is not an IDE.

Requirements change, so developers often expend considerable effort to make applications flexible and extensible. Eclipse is built around a highly flexible and extensible plug-in model to enable any type of tool to be added to the platform. If you begin to think of a desktop application as a tool, or set of tools, it immediately becomes apparent that your application functions and facilities can be added into an Eclipse-based desktop as a set of plug-ins, just as Eclipse's native Java IDE capabilities have been.

Eclipse provides a content model built around the concept of a workspace into which tools (applications) can be installed. The tools operate on resources that are organized into projects within the workspace. Projects contain a tree structure of resources, which are folders and files containing any type of content. The core platform provides a large number of extension points that allow customization of all aspects of resource life-cycle management.

With a bit of thought, the hierarchical, categorized nature of the content model lends itself to many types of desktop applications. For example, a simple e-mail client could be built on a workspace containing a single project associated with the user's e-mail account. The user's project could contain folders for the common functional e-mail elements such as inbox, outbox and sent items. Each of these folders could contain the corresponding set of e-mail messages as project resources.

The Eclipse platform contains a standard widget tool kit (SWT), which is implemented natively on all supported Eclipse platforms. SWT contains a large set of events, layout managers and widgets. When a supported platform does not contain a native widget that is supported by Eclipse, such as a toolbar on Motif, an emulated widget for that platform is provided. SWT also interacts with native desktop features, such as drag and drop. Additionally, SWT can use operating-system-specific components, such as Windows Active/X controls, if such functionality is more desirable than full platform portability. So far, SWT has been proved on the Windows Win32 and PocketPC, Photon, Motif and GNU window managers, covering deployment platforms from high-end workstations to embedded devices.

Although the Java language already contains two widget tool kits, Abstract Window Toolkit (AWT) and Swing, the Eclipse group chose to implement its own. The detailed reasons for this choice can be found in the Eclipse Overview white paper. But to prove to yourself that this was the right decision, compare the look and feel of a Swing or AWT application of your choice to that of Eclipse. Eclipse looks, feels and responds like a native application on whatever platform it is running. Naturally, this is also how you'd like your application to perform.

An application can be built upon the Eclipse framework by removing functions that you don't want and then adding functions that you do. Removing Eclipse functions is the easy part; just take out plug-ins that provide unneeded features. If you're not building another IDE, a good place to start is to remove all the plug-ins for Java development tools, plug-in development environment and version-control management. With that starting point and a bit of experience you can evaluate components and continue to remove unnecessary features by removing the corresponding plug-ins.

The user interface

Once you pare down the plug-ins to the bare minimum, you'll find that Eclipse still has a few development capabilities represented in the user interface (UI). To remove these from the framework, slightly more invasive techniques will have to be used. The workbench UI plug-in provides the base UI capabilities of Eclipse. Removing extensions from the plug-in's XML descriptor is an easy way to reduce visibility to the features that your application doesn't require.

After all unnecessary plug-ins are removed and you've minimized the extensions in the workbench UI, there is still one more avenue available to reduce the base framework size. Since Eclipse really was intended to be a framework for integrating development tools, a few of Eclipse's low-level development concepts are built into the workbench UI plug-in directly rather than being provided as extensions. The easiest way to remove them is simply to comment out the undesirable features in the source code and rebuild the plug-in. "Unwriting" a few bits of code is much easier and faster than writing an entire application framework. If you take this approach, however, you'll need to be able to repeat the changes when migrating to new versions of Eclipse source code, at least for a little while.

Version 3.0 of Eclipse, which is in development, has a stated goal that specifically seeks to enable the use of Eclipse as a rich client platform.

Once the unnecessary functions have been removed from the framework, building your application is simply a matter of writing your own plug-ins, adding features to the basic Eclipse framework and branding them with your own logos.

To completely remove all the IDE-centric features from Eclipse, source code modifications will be required until version 3.0 is available.

One of the most discussed Eclipse components has been the Standard Widget Toolkit. SWT is a thin layer that conforms the API calls for standard widgets like lists, buttons and text boxes into a transportable interface. There is no separate peer layer, as in the AWT class library. The SWT widget directly calls the underlying operating system's window manager.

Platform integration is not just a matter of look and feel. Tight integration includes the ability to interact with native desktop features such as cut and paste or drag and drop, or the ability to integrate with other desktop applications.

To bring some consistency to user interfaces implemented for the Eclipse Workbench, SWT includes support for creating custom widgets, leading to specific application look and feel. This consists of a small set of carefully designed components that have proved generally useful. The capabilities include extended support sensing, user-selected default, color selections and border widths using mechanisms provided by the operating system window manager.

The complete programmer's guide for working with SWT GUI components can be found in the Eclipse Project documentation found at www.eclipse.org/eclipse/index.html.

Todd E. Williams is vice president of technology at Genuitec LLC (Plano, Texas). Marc R. Erickson is Eclipse communications manager for IBM Corp. (Raleigh, N.C.).