Skip to main content

WindowBuilder

WindowBuilder

The WindowBuilder project is a proposed open source project under the Eclipse Tools Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the Eclipse community. Please send all feedback to the Eclipse Proposals Forum.

Background

A GUI builder is a visual programming tool that lets a user build a graphical user interface by dragging and dropping elements from a palette onto a design surface. GUI builders typically contain Wizards and templates that help automate the GUI building process. GUI building tools allow developers to spend less time and money creating Java GUIs, because they can focus on creating application-specific functionality rather than coding the low-level logic required for GUIs to run.

According to Ben Galbraith, in his Successful GUI Building blog, “In my experience, the number one reason why GUI builders hold appeal is that they often lead to an order of magnitude improvement in productivity over hand coding, especially amongst average-level Swing developers. I consider myself above average, and I see improvements in productivity around 2x-10x (perhaps higher) in my own work.”

Created in 2003 by Instantiations, WindowBuilder is widely regarded as the the best GUI builder in the Java world (winning the award for Best Commercial Eclipse Tool in 2009). Beyond being an exemplary example of a GUI design tool for SWT, XWT, Swing and Google’s GWT, WindowBuilder is also a highly extensible and customizable framework (with 50+ existing extension points) for creating new GUI design tools based on any UI toolkit for any language. Google re-launched WindowBuilder as a free product available to any member of the Eclipse community soon after its acquisition of Instantiations in 2010, and now wishes to contribute the framework (the WindowBuilder Engine) and associated products (SWT Designer and Swing Designer) to the Eclipse Foundation. Google will continue to invest heavily in the project, as it will continue to be the basis for its own in-house GWT Designer tool.

Scope

The scope of the project is to provide the definitive Eclipse extensible framework for creating GUI design tools for any language or UI framework. The current framework provides solid support for Java and XML based UI frameworks and exemplary tools for creating Swing and SWT UIs. Extending the framework to support additional languages (C++, JavaScript, PHP, etc.) and UI toolkits in the future is highly desirable.

Description

The WindowBuilder project goal will be to continue to develop the WindowBuilder Engine (WBE) framework for tool vendors wishing to support UI toolkits in a variety of languages. The framework currently has built-in support for Java-based (Swing, SWT, RCP, etc.) and XML-based (XWT) UI frameworks and can be extended to support any language for which a parser (and associated AST model) exists.

The project will also focus on continuing to develop and enhance the exemplary tool examples for SWT/RCP/XWT and Swing for the benefit of developers using Eclipse to build their own applications using those UI frameworks.

GUI building tools allow developers to spend less time and money creating Java GUIs. Here are some key features provided by the WindowBuilder Engine:

  • WYSIWYG visual designer and editing — The WBE takes the guesswork out of building and modifying a GUI. It contains both design and source views allowing developers to view content identical to the end result while the interface is being created.
  • Flexibility and consistency across frameworks — The WBE is easy to use and provides flexibility across different types of UI frameworks, meaning that the tool has a flexible parser to parse its own code as well as code written by hand or by other GUI building tools. It also provides a consistent development experience no matter which UI framework is being used.
  • Bi-directional code generation (round-trip editing) — Bi-directional code generation is important so that the visual design and source are always synchronized no matter which you edit.
  • Drag-and-drop — The WBE permits developers to implement exactly what they want, where they want it, by simply dragging and dropping GUI elements into the design layout view.
  • Wizards and templates — These features give developers a head-start in designing a GUI because they don’t have to re-create the basics.
  • Reverse engineering capabilities — The WBE allows a developer to read and write code coming from a variety of sources —such as code generated by other GUI builders, code created by hand, or code created in another application. This feature means that developers do not have to start from scratch on developing the GUI because they can use the existing code as a starting basis, especially with a product that is already in production.
  • Localization and Internationalization — Localization and internationalization capabilities allow the application under development to be easily adapted to various languages and regions without engineering changes. The WBE has powerful internationalization (i18n) support that helps automate the localization process. It can externalize component strings, create and manage resource bundles for multiple languages, and edit translated strings in context. The WBE allows developers to switch which language is used to render the GUI on the fly to see the effect of different length strings. The WBE makes it easy to support different languages by adding existing locales or creating new locales from existing language and country codes.
  • Minimal code changes — The WBE makes minimal edits to the source code and maintains changes made by developers to customize the GUI. The tool knows which lines of code are GUI-related and parses only those. It ignores non-GUI code added by the user and preserves that code any time it edits the file. The WBE uses a style of micro editing that ensures that the smallest possible change is made to the source, again preserving all user code and formatting.
  • Morphing tools — The WBE contains advanced features such as a Morphing tool that allows the developer to change one widget type into another.
  • Visual inheritance — The WBE supports visual inheritance so that code can be inherited from a parent-child hierarchy. Visual Inheritance is the inheritance of visual elements in a window such as buttons and panels in derived GUI classes. Inheriting forms is a powerful feature that allows standardization of common GUI elements on a window that may be changed in one place rather than in countless individual windows.
  • Factories — The WBE supports the creation of custom factory classes and methods. This is a convenient way to create customized, reusable versions of common components. It allows developers to create a static factory method from any widget, morph any widget into a factory instance, or add any factory component to the palette. This feature saves time and is a good method of building versions of commonly used components.
  • Data Binding — The WBE supports Data binding which allows easy linking of UI elements and models so that users can edit or view the data in the model. Traditionally, this is what you need to do to link, for example, a text widget to a String property of a model object.
  • Auto-discovery of UI supported frameworks — The WBE supports the automatic discovery and one-click loading of supported UI frameworks. For example, a developer using the WBE and SWT tools can easily load the Swing tools if needed and vice versa.

Initial Contribution

The initial contribution will be composed of three main parts:

  • WindowBuilder Engine — the core extensible framework providing support for all of the features listed above.
  • SWT Designer — an exemplary implementation of an GUI design tool that supports SWT, JFace, RCP, eRCP and XWT. This tool also provides excellent support for the Nebula widget collection and the Eclipse Data Binding framework.
  • Swing Designer — an exemplary implementation of an GUI design tool that supports Swing. This tool also provides excellent support for 3rd party layout managers such as JGoodies FormLayout and MiGLayout as well as support for the Swing Data Binding framework.

The goal is to provide an even more useful framework and associated tools, so contributions from the community are welcome. Example contributions that we would hope to see include:

  • Support for new widgets and widget collections
  • Support for new layout managers
  • Support for new localization patterns
  • Support for new Java and XML based UI frameworks
  • Support for new languages and associated frameworks
  • Support for additional operating systems beyond Windows, Linux and OSX
  • Support for additional extension points for further customizing the tool

Legal Issues

No legal issues are anticipated although all 3rd party code used in the product will go through the standard Eclipse IP process.

Relationships to other Eclipse projects

The WindowBuilder project has the following relationships to other Eclipse projects:

  • WindowBuilder directly competes with the Visual Editor Project (VEP).
  • WindowBuilder makes heavy use of the Java Development Tools (JDT). The Java Editor is embedded in the WindowBuilder editor to create the Source page. The WBE builds a JDT AST model for reverse engineering Java code.
  • WindowBuilder uses the Plug-in Development Environment (PDE) to create plug-in and RCP components like Views and Editors and update the plugin.xml and manifest.mf files.
  • WindowBuilder embeds the XML editor from the Web Standard Tools (WST) as the Source page when editing XML-based UIs.
  • The SWT tooling uses and generates code to support the following Eclipse frameworks: SWT, RCP, eRCP, XWT and Nebula. Some support is also available for RAP and Riena based applications.

Committers

The following individuals are proposed as initial committers to the project:

  • Eric Clayberg, Google
    Eric has been the project manager of the existing WindowBuilder project over the last seven years and will continue to be heavily involved in all facets of the project going forward as the Project Lead.
  • Konstantin Scheglov, Google
    Konstantin is the chief architect and technical lead for the existing WindowBuilder project at Google (formerly at Instantiations) and will continue to be heavily involved in all facets of the project going forward.
  • Alexander Mitin, Google
    Alexander has been on of the key developers for the existing WindowBuilder project over the last seven years and will continue to be heavily involved in all facets of the project going forward.
  • Andrey Sablin, Google
    Andrey has been a developer on the existing WindowBuilder project for the last two years and will continue to be heavily involved in all facets of the project going forward.
  • Jaime Wren, Google
    Jaime has been a developer on the existing WindowBuilder project for the last two years and will continue to be heavily involved in all facets of the project going forward.
  • Dan Rubel, Google
    Dan has been a contributor on the existing WindowBuilder project for the last seven years and will continue to be involved in all facets of the project going forward.
  • Mark Russell, Google
    Mark has been a build master for the existing WindowBuilder project for the last five years and will continue to be responsible for build-related issues going forward.
  • Devon Carew, Google
    Devon is interested in contributing to the project.
  • Rajeev Dayal, Google
    Rajeev is interested in contributing to the project.
  • Miguel Mendez, Google
    Miguel is interested in contributing to the project.
  • David Carlson, Google
    David is interested in contributing to the project.
  • Alexander Humesky, Google
    Alexander is interested in contributing to the project.
  • Xavier Ducrohet, Google
    Xavier is interested in contributing to the project.
  • Raphael Moll, Google
    Raphael is interested in contributing to the project.
  • Tor Norbye, Google
    Tor is interested in contributing to the project.
  • Ed Merks, Cloudsmith
    Ed is interested in Data Binding features.
  • Kenn Hussey, Cloudsmith
    Kenn is interested in Data Binding features.
  • Christian Campo, compeople AG
    Christian is interested in SWT features to support Riena.
  • Neeraj Bhusare, Genuitec
    Neeraj is interested in Swing tools.
  • Piotrek Tomiak, Genuitec
    Piotrek is interested in Swing tools.
  • Vadim Ridosh, Genuitec
    Vadim is interested in tools for mobile apps.

We welcome additional committers and contributions.

Mentors

The following Architecture Council members will mentor this project:

  • Ed Merks
  • Kenn Hussey

Interested Parties

The following individuals, organizations, companies and projects have expressed interest in this project:

  • Cloudsmith — interested in all aspects (esp. Data Binding)
  • Genuitec — interested in taking the lead on Swing Designer
  • Eclipse Riena Team — interested in WBE & SWT Designer
  • Motorola — interested in mobile UI tools

Project Scheduling

Changes to this Document

Date Change
01-Dec-2010 Document created
15-Dec-2010 Document released for public review

Back to the top