Article-UI-Guidelines/Contents.html - www.eclipse.org/articles - Git at Google

 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 <meta name="Author" content="Nick Edgar, Kevin Haaland, Jin Li and Kimberley Peter">
 <meta name="keywords" content="Eclipse UI Guidelines, User Interface, Guidelines, HCI, User Experience, Usability, Human Factors">
 <title>Eclipse User Interface Guidelines</title>
 <link HREF="default_style.css" REL="stylesheet">
 <link HREF="../version.css" REL="stylesheet">
 <style type="text/css">
 <!--
 .tocstyle {  font-family: Arial, Helvetica, sans-serif; font-size: 10px}
 -->
 </style>
 </head>
 <body>

 <div align="right"> Copyright&copy; 2001-2004 International Business Machines Corp.&nbsp;
   <table BORDER=0 CELLSPACING=0 CELLPADDING=2 WIDTH="100%" >
 				<tr>
 					<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica"><font color="#FFFFFF">&nbsp;Guidelines</font></font></b></td>
 				</tr>
 			</table>
 		</div>

 <h1>
 <img src="images/Idea.gif" height=86 width=120 align=CENTER></h1>

 <center>
 <h1>
 Eclipse User Interface Guidelines<BR>Version 2.1
 </h1>
 <p><a href="Index.html" target="_top">View with table of contents</a></p>
 </center>

 <br>
 <center>
 <p><br><b><font color="#000000">Nick Edgar, Kevin Haaland, Jin Li and Kimberley Peter</font></b>
   <p><b><font color="#000000">Last Updated: February 2004</font></b>
 </center>


 <h3>
 <font color="#000000">Notice</font></h3>
 <font color="#000000">Your feedback can influence the ideas and guidelines described here.&nbsp; If you have suggestions,
 <A href="mailto:platform-ui-dev@eclipse.org?subject=UI Guidelines v2.1 Feedback">please provide us with your feedback here.<BR>
 </A></font>

 <div class="version-info">The contents of this article has been moved to the <a target="_top" href="http://wiki.eclipse.org/User_Interface_Guidelines">Eclipse Wiki</a>.
 Please look there for the most up-to-date information.</div>
 <br>
 <h2>
 <a NAME="Introduction"></a>Introduction</h2>
 In this document the Eclipse user interface guidelines are defined.
 <p>Eclipse is a universal tool platform - an open, extensible IDE for anything,
 but nothing in particular. The real value comes from tool plug-ins that
 "teach" Eclipse how to work with things - Java&trade; files, Web content, graphics,
 video - almost anything you can imagine. Eclipse allows you to independently
 develop tools that integrate with other people's tools so seamlessly, you
 won't know where one tool ends and another starts. The very notion of a
 tool, as we know it, disappears completely.
 <p>The platform is very flexible and extensible, but this flexibility has
 a serious drawback.&nbsp; In particular, there is no way within the program
 to ensure user interface consistency between the registered components
 within the platform.&nbsp; This document attempts to reconcile this problem,
 by defining standard user interface guidelines for the creation of new
 components.&nbsp; If these guidelines are adopted within your own tools,
 it will lead to greater consistency with the platform and other tools,
 and an easier learning curve for your customers.
 <p>These guidelines are intended for use by designers and implementors
 of an Eclipse user interface extension.
 <br>&nbsp;
 <h3>
 <a NAME="The Workbench"></a>The Workbench</h3>
 To start out, let's take a look at the Eclipse workbench user interface, and the
 various components within it.
 <p>The workbench is a collection of windows.&nbsp; Each window contains
 a menu bar, a toolbar, a shortcut bar and one or more perspectives.


 <p><img src="images/workbench_decomposed.gif" hspace="40" height=713 width=794>

 <p>
 A perspective
 is a visual container for a set of views and content editors.&nbsp; The views
 exist wholly within the perspective and are not shared, but any opened content
 editors are shared across perspectives.&nbsp; If two or more perspectives have the same view opened, they share the same instance of the view although its layout may differ in the perspectives.  For perspectives in different Workbench windows, neither editors nor views are shared. A perspective
 is like a page within
 a book.&nbsp; It exists within a window along with any number of other
 perspectives and, like a page within a book, only one perspective is visible
 at any time.

 <p>The Workbench's main menu bar usually contains the File, Edit, Navigate, Project, Window, Help top-level menus. Other top-level menus that are in between
 the Edit and Project menu are typically context specific, based on the
 current active perspective, front most editor (whether active or not), and active view..

 <p>In the File menu you will find a New submenu, which contains menu items
 for Project, Folder, and File creation.&nbsp; The File menu also contains
 menu items for Import and Export, which are used to import files into the
 Workbench, and export them out again.&nbsp; In the Edit menu, you will
 find familiar commands like Cut, Copy, Paste, and Delete.&nbsp; These commands
 are known as global commands, and target the active part.
 In other words, if the Delete command is invoked with
 the Navigator active, the actual implementation is performed by the Navigator.
 &nbsp; In the Project menu, you will find project related commands such as Open project,
 Close project and Rebuild project are available.&nbsp; In the Run menu,
 you will find commands related to running and debugging application code,
 and launching external tools such Ant scripts.&nbsp;
 In the Window menu, you will find the Open Perspective submenu to open different
 perspectives to suit to needs of your development tasks.&nbsp; You will find perspective
 layout management menu items.&nbsp; You will also find the
 Show View submenu to add views to the current Workbench window.&nbsp;
 In addition, you will find the Preferences menu item, which is used to modify the functional
 preferences of the Workbench.
 <p>As a plug-in developer, you can contribute new views, editors, wizards,
 menu, and tool items to the platform.&nbsp; These contributions are defined
 using XML, and once registered, integrate seamlessly with the components
 which already exist in the platform.
 <h3>
 <a NAME="Projects, Folder and Files"></a>Projects, Folders and Files</h3>
 Eclipse can be used to create many different kinds of content - Java files, Web content, graphics,
 video - almost anything you can imagine.&nbsp; These objects are stored
 as regular files within the Eclipse workspace.&nbsp; The workspace consists
 of one or more top level projects.&nbsp; Each project contains a collection
 of folders and files.&nbsp; These objects are known as <i>resources</i>.
 <br>&nbsp;
 <p>

 <h2>
 <a NAME="Getting Started"></a>Getting Started</h2>
 For most developers, an introduction to the platform can be overwhelming,
 and you may ask "where do I get started?".&nbsp; Here are a few basic guidelines
 which will help you.

 <p>This document is intended for UI designers and developers.&nbsp; With this audience
 in mind, we can talk about the two main layers of any application: the
 model layer and the user interface layer.&nbsp; In the model layer of Eclipse,
 known as the Workspace, is a collection of resources (projects, folders
 and files).&nbsp; The user interface, or the Workbench, defines the presentation
 for those resources.

 <p>As a UI developer, you will also have a model and a presentation.&nbsp;
 If we assume that your goal is to make the model visible, through some
 presentation, most developers will start out by adding a new view or editor
 to the workbench.
 <p><font color="#000000">In Eclipse, an editor is used to contain the primary content, such as a document or data object, which users interact with.&nbsp;In every case, this content is the primary focus of attention and a reflection
 of the primary task.&nbsp; To illustrate this concept, let's look at some
 common examples.</font>

 <p><font color="#000000">To do Java programming, the primary task is to
 create, edit, and debug Java code. The primary focus is the Java code,
 so an editor is used to interact with that code.&nbsp; The navigator, outline,
 and properties view exist to support the primary task, but rarely hold
 your attention for an extended period of time while you are writing Java
 code.</font>

 <p><font color="#000000">To read email, the primary task is to create,
 send, read, and reply to email. The primary focus is a particular email
 message, so an editor is used to view or reply to an email message.&nbsp;
 A view may be used to select an email message to read, and open an editor.</font>

 <p><font color="#000000">To communicate using instant messaging, the primary
 task is the conversation.&nbsp; The primary focus is a particular conversation,
 so an editor is used to carry on that conversation.&nbsp; A view may be
 used to list people with whom you can initiate a conversation.</font>

 <p><font color="#000000">To browse the Web, the primary task is reading.
 The primary focus is a particular Web page, so an editor is used to browse
 the Web page.</font>

 <p><font color="#000000">In each case, the primary task determines the primary
 focus of attention. As the primary focus of attention, it deserves a primary
 position in the UI</font> <font color="#000000">(as an editor), and can contribute
 commands to the workbench's main menu bar and toolbar.</font>

 <p><font color="#000000">A view may be used to save your favorite links, and reopen
 them.&nbsp; At any time, you may decide to edit the page you are looking at.&nbsp;
 This causes a new editor to open. Views are used to support the primary task.&nbsp; You
 use them to navigate a hierarchy of information, open an editor, or view properties
 for the active part.&nbsp; Each view may have its own local toolbar and local menu bar.</font>

 <p>Once you have added a view or editor, an interesting question arises.&nbsp;
 Where did this model come from?&nbsp; In Eclipse, most data is created
 using a creation wizard.&nbsp; You may want to add a creation wizard too.
 And once an object exists, you may need a way to edit the properties for
 that object using a properties page, or the properties dialog.

 <p>All of these ideas will be discussed, in detail, in the following sections.
 <p>

 <br>
 <h2>
 <a NAME="General UI Guidelines"></a>General UI Guidelines</h2>


 <br>This document defines UI guidelines that are unique and specific to
 the Eclipse platform. It is a supplement to the other standard UI guidelines
 such as Microsoft&reg; User Experience, Macintosh Human Interface Guidelines,
 and Java Look and Feel Guidelines. You should continue to consult those
 guidelines for basic UI design and implementation recommendations.
 <p>It is expected that you already have a basic understanding of the Eclipse
 UI architecture and APIs, and the basic UI design principles: user in control,
 directness, consistency, forgiveness, feedback, aesthetics, and simplicity.
 If you do not currently have the prerequisite knowledge, please read the
 relevant documentation first.

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <font color="#09448D"><b>Guideline 1.1</b></font>
 <blockquote><font color="#09448D">Follow and apply good user interface
 design principles: user in control, directness, consistency, forgiveness,
 feedback, aesthetics, and simplicity.</font></blockquote>
 </p>

 <hr>

 <h3>
 <a NAME="The Spirit of Eclipse"></a>The Spirit of Eclipse</h3>
 At its heart, Eclipse is a platform for tool plug-ins.&nbsp; These plug-ins
 may be developed by a single team or by a partnership of teams, or the
 user may assemble a set of plug-ins from diverse sources.&nbsp; In either
 case, the usability of an individual tool, and Eclipse as a whole, will
 be positively influenced by user interface consistency.
 <p>If you're in doubt about the appropriate look and feel for a tool, look
 to the platform first, then the Java development tooling and the Plug-in Development Environment (PDE) in Eclipse for
 guidance. In many cases, the workflow you imagine may already exist in
 Eclipse.&nbsp; If so, adopt the platform's workflow and user interface
 conventions. This will lead to greater consistency with the platform and
 other plug-ins, and an easier learning curve for your customers.

 <p>In some scenarios, it may be tempting to ignore the workflow of Eclipse and
 implement a "custom" user interface.&nbsp; This interface will almost certainly
 stand out like a sore thumb in an integrated environment, where other tools
 adopt the platform conventions.&nbsp; You lose the benefit of past experience,
 and force your customers to learn new ideas.

 <p>Consult the <A href="#Best Practices" target="_right">Best Practices</A> section for examples and more information.

 </P>
 <P>Also, visit the <A
 	href="http://www.eclipse.org/newsgroups/index.html" target="_blank">Eclipse
 platform newsgroups</A> to share information with the community.</P>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.2</font></b>
 <blockquote><font color="#006699">Follow the platform lead for user interface
 conventions.</font></blockquote>
 <hr>
 </p>

 If you decide to reuse the conventions of Eclipse, be careful not to misappropriate
 Eclipse specific UI conventions.&nbsp; For instance, the active part in
 a workbench window is indicated by a shaded title.&nbsp; The use of shaded
 titles within an editor (see below) may be one way to indicate where the
 focus is, within that part, but it will also blur the concept of part activation
 in the window.
 <p><img src="images/badHilight.gif" hspace="40" height=423 width=702>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.3</font></b>
 <blockquote><font color="#09448D">Be careful not to mix UI metaphors.&nbsp;
 It may blur the original concept, and your own application.</font></blockquote>
 <hr>
 </p>

 Eclipse is an open source project.&nbsp; If you feel your ideas are generally
 useful, join the Eclipse community, write a proposal, and work with the
 Eclipse community to make Eclipse a better platform for product development
 and increase customer satisfaction.
 <p>Visit <A href="http://www.eclipse.org" target="_blank">www.eclipse.org</A> and join the Eclipse UI mailing list <B>platform-ui-dev</B>.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.4</font></b>
 <blockquote><font color="#09448D">If you have an interesting idea, work
 with the Eclipse community to make Eclipse a better platform for all.</font></blockquote>
 <hr>
 </p>

 <h3>
 <a NAME="Capitalization"></a>Capitalization</h3>
 Consistent capitalization of text within a plug-in leads to a more polished
 feel, and greater perception of quality.&nbsp; Within a dialog or window,
 headline capitalization should be applied to all titles, menus, tooltip, tabs, and push buttons.&nbsp;For example, &quot;Run to Line&quot; can be used as a menu item label.
 <P>Sentence style capitalization should
 be applied to all check boxes, radio buttons, and group labels.
 For example, &quot;Choose an option for the Java file&quot; can be used as a group label.</P>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b> <font color="#09448D">Guideline
 1.5</font></b>
 <blockquote><font color="#09448D">Use Headline style capitalization for
 menus,  tooltip and all titles, including those used for windows, dialogs, tabs, column headings
 and push buttons. Capitalize the first and last words, and all nouns, pronouns,
 adjectives, verbs and adverbs.&nbsp; Do not include ending punctuation.</font></blockquote>

 <img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.6</font></b>
 <blockquote><font color="#09448D">Use Sentence style capitalization for
 all control labels in a dialog or window, including those for check boxes,
 radio buttons, group labels, and simple text fields.&nbsp; Capitalize the
 first letter of the first word, and any proper names such as the word Java.</font></blockquote>
 <hr>
 </p>


 <h3>
 <a NAME="Language"></a>Language</h3>
 Eclipse is available on a variety of different platforms, in a variety of
 locales.&nbsp; In reflection of the different languages and numeric formats
 in each, a localization strategy should be adopted for the text and images
 within each plug-in.&nbsp; This involves the separation of all resources
 from the source code of a plug-in itself, so that those resources can be
 translated to a new locale.
 <P>Consult the <A href="#Best Practices" target="_right">Best Practices</A> section for examples and more information.</P>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.7</font></b>
 <blockquote><font color="#09448D">Create localized version of the resources within your plug-in.</font></blockquote>

 <hr>
 <h3>
 <a NAME="Error Handling"></a>Error Handling</h3>
 If an error occurs in Eclipse, the appropriate response will be dependent
 on the context of the error.
 <p>Please refer to <A href="#Wizards">Wizards</A>
 section  for guidelines on how to handle user input errors in a wizard.
 <p>Please refer to <A href="#Editors">Editors</A>
 section for guidelines on how to handle errors occur in an editor, .
 <p>When an error occurs which requires either an explicit user input or
 immediate attention from users, a modal dialog should be used to communicate
 the error to the user.&nbsp; This forces the user to notice, and deal with
 the problem.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 1.8</font></b>
 <blockquote><font color="#09448D">When an error occurs which requires either
 an explicit user input or immediate attention from users, communicate the
 occurrence with a modal dialog.</font></blockquote>

 <hr>
 <P>
 If a programming error occurs in the product, an error dialog should be
 used to communicate the occurrence to the user.&nbsp; The error should
 also be logged using the workbench error logging facility.&nbsp; This gives
 the user an opportunity to restart the platform, uninstall the corresponding feature,
 and contact their system administrator.
 <p>The plug-in should provide the following information in the detail area
 of the error dialog:
 <ul>
 <li>
 Provider name</li>

 <li>
 Plug-in name (user friendly name)</li>

 <li>
 Plug-in ID</li>

 <li>
 Version</li>
 </ul>
 <img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 1.9</font></b>
 <blockquote><font color="#09448D">If a programming error occurs in the
 product, communicate the occurrence with a dialog, and log it.</font></blockquote>

 <br>
 <h2><a NAME="Introduction_VDG"></a>Visual Design</h2>

 <p>
 All visual user interface elements created for Eclipse follow a common style called the
 <strong><i>Eclipse visual style</i></strong> or <strong><i>Eclipse style</i></strong>.
 In these guidelines you will find basic design information, as well as specifications for
 implementing Eclipse style icons and wizard graphics in tools based on the Eclipse framework.

 <p>
 Following these guidelines will help ensure consistency of visual user interface elements and their implementation
 across the Eclipse tools and plug-ins. Consistency of these elements includes visual semantic, style, and
 implementation considerations. These topics are covered in the following sections.


 <!-- CONSISTENCY SECTION STARTS -->
 <!-- Consistency -->

 <p>
 <h3><a NAME="Consistency_VDG">Consistency</a></h3>
 <p>
 In the development of the Eclipse style icons, a visual language was formed to describe a variety of concepts in the
 user interface. These concepts are now represented by a large selection of tiny visual signs that many have come to know
 through using Eclipse tools.</p>
 <p>In order to ensure a consistent visual experience, understanding of concepts across the tools, and minimize
 confusion for the user, we encourage you to re-use Eclipse style graphical elements whenever possible.</p>

 <br>
 <h4><a NAME="ConsistencyConcept_VDG">Icon Reuse</a></h4>
 <p>
 A great many icons have already been created in the Eclipse visual style so there is a good chance many of the icons or
 graphical elements you may need already exist. A sample of the core concepts is shown in the following table. Each of these
 elements carries with it a specific meaning, so care should be taken when using them to ensure that consistent meaning
 is maintained.</p>

 <p><IMG height="423" alt="metaphor example" src="images/metaphor_concepts.gif" hspace="40" width="658" border="0"></p>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.1</font></b>
 <blockquote><font color="#09448D">Re-use the core visual concepts to maintain consistent representation and meaning
 across Eclipse plug-ins.</font></blockquote></p>

 <br>

 <!-- ICON SPECIFICATION SECTION STARTS -->
 <!-- Icon Specifications / Icon Palettes -->
 <br>
 <h3><a NAME="IconSpecsPal_VDG">Icon Palettes</a></h3>
 <p>Various palettes used in creating Eclipse style icons.
 There are 3 different palettes used to create the 3 different icon states, as follows:</p>
 <ul>
 <li>
 <strong>256 Color Palette</strong> for the active or selected &mdash; also referred to as "color"&mdash; state of all icon types
 </li>
 <li>
 <strong>8 Color Grayscale Palette</strong> for the enabled state of perspective, view, toolbar, toolbar wizard, and local toolbar icons
 </li>
 <li>
 <strong>2 Color Grayscale Palette</strong> for the disabled state of toolbar, toolbar wizard, and local toolbar icons
 </li>
 </ul>

 <br>
 <h4>256 Color Palette</h4>
 <p>
 Eclipse style icons should be designed using a special 256 color palette that consists of
 20 standard colors and 236 custom colors, as shown below.
 <p>
 <IMG alt="newwin256.act" src="images/256palette.gif" hspace="40" width="194" height="193" border=0>
 </p>

 <p><strong>NOTE:</strong>&nbsp;
 Although the color palette shown is based on the standard windows .aco
 color palette that comes with Adobe Photoshop, these two palettes are NOT the same and ONLY the
 shown color palette should be used when creating Eclipse style icons.
 </p>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.2</font></b>
 <blockquote><font color="#09448D">Use the Eclipse 256 color palette for creating the active or selected state of
 all icon types.</font></blockquote></p>
 <hr>

 <br>
 <h4>8 Color Grayscale Palette</h4>
 <p>To create grayscale, enabled versions of your full color icons, you will need to use another
 palette that consists of the 8 colors shown below:</p>
 <br>
 <IMG height=80 alt="enabled colors" src="images/enabledcolors.gif" hspace="40" width="401" border="0">

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.3</font></b>
 <blockquote><font color="#09448D">Use the Eclipse 8 color palette for creating the enabled state of perspective,
 view, toolbar, toolbar wizard, and local toolbar icons.</font></blockquote></p>
 <hr>

 <br>

 <p><h4>2 Color Grayscale Palette</h4></p>
 <p>To create grayscale, disabled versions of your full color and enabled icons, you will need to use
 a subset of the 8 color palette, that consists of the 2 colors shown below:
 </p>
 <br>
 <IMG alt="disabled colors" src="images/disabledcolors.gif" hspace="40" width="158" height="50" border="0" >

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.4</font></b>
 <blockquote><font color="#09448D">Use the Eclipse 2 color palette for creating the disabled state of toolbar,
 toolbar wizard, and local toolbar icons.</font></blockquote></p>
 <hr>

 <!-- Icon Specifications / Icon Types -->
 <br>
 <br>
 <h3><a NAME="IconSpecsTypes_VDG">Icon Types</a></h3>

 <p>
 The Eclipse style icons have been categorized into separate types so that each can be optimized for its specific
 location within the user interface. Below is a breakdown of these types and where they are located.
 </p>

 <br>
 <IMG height=345 alt="icon types" src="images/icon_types.gif" hspace="40" width =539 border=0>
 <br>
 <p>
 <STRONG><FONT size=4>A&nbsp;&nbsp;&nbsp;</FONT>Product</STRONG>
 <br>The Product icon represents the branding of the product, and is always located on the far left
 of the window title bar before the perspective, document, and product name.
 </p>

 <p>
 <strong><font size=4>B&nbsp;&nbsp;&nbsp;</font>Perspective and Fastview</strong>
 <br>Perspective and fastview icons are found down the left side of the workbench. These icons allow the user to quickly
 switch between different opened perspectives, or to invoke different views
 that have been created as fastviews.
 <br></p>

 <p>
 <STRONG><FONT size=4>C&nbsp;&nbsp;&nbsp;</FONT>Toolbar</STRONG>
 <BR>Toolbar icons are found on the main toolbar across the top of the workbench. These icons invoke
 a command, either globally or within the editor.
 <br></p>

 <p>
 <STRONG><FONT size=4>D&nbsp;&nbsp;&nbsp;</FONT>Toolbar Wizard</STRONG>&nbsp;
 <BR>Toolbar wizard&nbsp;icons are found on the main toolbar across the top of the workbench.
 They are easily recognized by their wand and sparkle. Selecting one of these
 icons will launch a wizard.
 <br></p>

 <p><strong><font size=4>E&nbsp;&nbsp;&nbsp;</font>View</strong>
 <br>
 View icons are found on the left side of the titlebar of
 each view within the workbench. These icons indicate each views function.
 <br></p>

 <p>
 <STRONG><FONT size=4>F&nbsp;&nbsp;&nbsp;</FONT>Local (View) Toolbar</STRONG>
 <br>Local toolbar icons are found to the right of the view icon on the titlebar of each view
 within the workbench. These icons invoke a command on objects in that view only. Local toolbar icons
 are also found in all menus, including main, pull down, and context menus.
 <br></p>

 <p>
 <STRONG><FONT size=4>G&nbsp;&nbsp;&nbsp;</FONT>Model Object</STRONG>
 <br> Model Object icons are found in tree views, list views, and on Editor Tabs within the the workbench
 (such as files, folders, projects and so on).
 <br></p>

 <p>
 <STRONG><FONT size=4>H&nbsp;&nbsp;&nbsp;</FONT>Object Overlay</STRONG>
 <br>Object overlay icons are also found in tree or list views. They are appended to the various
 corners of model object icons as signifiers of some sort of change.
 </p>


 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.5</font></b>
 <blockquote><font color="#09448D">Use the appropriate icon type in the location it is designed for within the
 user interface.</font></blockquote></p>
 <hr>


 <!-- Icon Specifications / Icon Size & Placement -->
 <br>
 <br>
 <h3><a NAME="IconSpecsSize_VDG">Icon Size &amp; Placement</a></h3>
 <p>
 With few exceptions, Eclipse style icons are designed within an area of 16 x 16 pixels. Within that area, a 15 x 15 pixel
 space is reserved for the image itself, leaving both a vertical and horizontal line of empty pixels to allow for proper
 placement of the image within the interface. Note the location of the empty pixels in the samples below. The icons are
 cut with the specific placement shown to ensure alignment in the user interface.
 </p>

 <P>The diagrams below show the proper sizing of the separate types of icons, and their proper placement within the
 allotted screen space.</P>

 <table cellpadding="0" cellspacing="0" border="0" width="100%">

 <tr><td valign="top" width="200">
 <IMG height="185" alt="view real estate" src="images/view_realestate.gif" hspace="40" width="180" border="0" >
 </td>
 <td valign="top">
 <p>
 <b>View Icons</b>
 <br>
 Maximum 16 pixels wide x 16 pixels high, always centered.<br>
 Empty pixels must be on the left, and bottom.</p>

 </td></tr>

 <tr><td valign="top">
 <IMG height="185" alt="perspective real estate" src ="images/perspective_realestate.gif" hspace="40" width=180 border=0 >
 </td>
 <td valign="top">
 <p>
 <b>Perspective Icons</b>
 <br>
 <b>Fastview Icons</b>
 <br>
 Maximum 16 pixels wide x 16 pixels high, always centered.<br>
 Empty pixels must be on the right, and bottom.</p>

 </td></tr>

 <tr><td valign="top">
 <IMG height="185" alt="toolbar real estate" src ="images/toolbar_realestate.gif" hspace="40" width=180 border=0 >
 </td>
 <td valign="top">
 <p>
 <b>Toolbar Icons</b>
 <br>
 <b>Toolbar Wizard Icons</b>
 <br>
 <b>Local Toolbar Icons</b>
 <br>
 Maximum 16 pixels wide x 16 pixels high, always centered.<br>
 Empty pixels should be on the left, and top.</p>

 </td></tr>

 <tr><td valign="top">
 <IMG height="185" alt="view real estate" src ="images/view_realestate.gif" hspace="40" width=180 border=0 >
 </td>
 <td valign="top">
 <p>
 <b>Model Object Icons</b>
 <br>
 Maximum 16 pixels wide x 15 pixels high, always centered.<br>
 Model Object icons must be no greater than 15 pixels high.
 <p></p>
 </td></tr>

 <tr><td valign="top">
 <IMG height="105" alt="overlay real estate" src ="images/overlay_realestate.gif" hspace="40" width=180 border=0 >
 </td>
 <td valign="top">
 <p>
 <b>Object Overlay Icons</b>
 <br>
 Object Overlays are one of the exceptions to the 16 x 16 pixel size.
 <br>
 Maximum 7 pixels wide x 8 pixels high, always centered.<br>
 Icon should have a white outside keyline around it to separate it from the icon it is being appended to.
 <br>
 See the next section on Icon Positioning for using the keyline on different types of Object Overlay icons.</p>
 </td>
 </tr>
 </td>
 </tr>
 </table>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.6</font></b>
 <blockquote><font color="#09448D">Follow the specific size specifications for each type of icon.</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.7</font></b>
 <blockquote><font color="#09448D">Cut the icons with the specific placement shown to ensure alignment in the user interface.</font></blockquote></p>
 <hr>


 <!-- Icon Specifications / Icon Positioning -->
 <br>
 <br>
 <h3><a NAME="IconSpecsPos_VDG">Icon Positioning</a></h3>
 <p>
 To follow from the specific size and placement of the different types of icons within their allotted screen space, the
 following positioning guidelines will help with the alignment of these elements relative to one another, and will aid
 in creating a well organized and aesthetically integrated user interface. (All measurements are in pixels.)
 </p>

 <br>
 <h4>Overview</h4>
 <IMG hspace="40" height="350" alt="overview image of the four different icon position areas detailed below" src="images/iconposition_main.gif" border=0>
 <br>
 <br>
 <br>

 <h4>1. Toolbar icons</h4>
 <p class="sub">(Includes Toolbar and Toolbar Wizard Icons)
 </p>
 <p>
 <IMG hspace="40" height="260" alt="toolbar specifications" src="images/toolbar_specs.gif" border="0">
 </p>

 <table cellspacing="2" cellpadding="4" border="0">
 <!-- 1st row : table categories -->
 		<tr>
 		<td rowspan="12" width="40px"></td>
 		<td></td>
 		  <td><strong>Item</strong></td>
 		  <td><strong>Positioning and Spacing</strong></td>
 		</tr>

 		<!-- 2nd row : beginning of table contents -->
 		<tr>
 		<td><strong>A</strong></td>
 		  <td>Toolbar</td>
 		  <td>22 pixels high</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Between left margin and handle</td>
 		  <td>4 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>C</strong></td>
 		  <td>Between handle and first icon</td>
 		  <td>7 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>C</strong></td>
 		  <td>Between icon and top of toolbar</td>
 		  <td>3 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>C</strong></td>
 		  <td>Between icon and bottom of toolbar</td>
 		  <td>3 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>C</strong></td>
 		  <td>Between icon and twisty</td>
 		  <td>7 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>D</strong></td>
 		  <td>Between twisty and hard rule</td>
 		  <td>7 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>E</strong></td>
 		  <td>Between hard rule and icon</td>
 		  <td>6 pixels</td>
 		</tr>

 		<tr>
 		<td><strong>F</strong></td>
 		  <td>Between icons</td>
 		  <td>7 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>G</strong></td>
 		  <td>Between icon and hard rule</td>
 		  <td>10 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>H</strong></td>
 		  <td>Between hard rule and handle</td>
 		  <td>2 pixels</td>
 		</tr>
 		</table>
 <br>
 <br>

 <h4>2. Titlebar icons</h4>
 <p class="sub">(Includes View and Local Toolbar Icons)</p>

 <IMG hspace="40" height="162" alt="titlebar specifications" src="images/titlebar_specs.gif" border=0 >
 <br>
 <table cellspacing="2" cellpadding="4" border="0">
 		<tr>
 		<td rowspan="9" width="40px"></td>
 		<td></td>
 		  <td><strong>Item</strong></td>
 		  <td><strong>Positioning and Spacing</strong></td>
 		</tr>
 		<tr>
 		<td><strong>A</strong></td>
 		  <td>Title bar</td>
 		  <td>22 pixels high</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>

 		  <td>Between left margin and view icon</td>
 		  <td>4 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Between view icon and text label</td>
 		  <td>3 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Between title bar icons and top of title bar</td>
 		  <td>3 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Between title bar icons and bottom of title bar</td>
 		  <td>3 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>C</strong></td>
 		  <td>Between local toolbar icons</td>
 		  <td>7 pixels</td>
 		</tr>
 		<tr valign="top">
 		<td><strong>D</strong></td>
 		  <td width="320">Between last local toolbar icon and closing window 'x'</td>
 		  <td>7 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>E</strong></td>
 		  <td>Between closing window 'x' and right margin</td>
 		  <td>4 pixels</td>
 		</tr>
 		</table>
 		<br>
 		<br>

 		<h4>3. Perspective icons</h4>
 		<p class="sub">(Includes Perspective and Fastview Icons)
 		</p>


 	<table cellpadding="0" cellspacing="0" border="0">
 	<tr valign="top">
 	<!-- TD 1 begins -->
 	<td>
 	<IMG hspace="40" height="500" alt="perspective specifications" src="images/perspective_specs.gif" border="0" >
 	</td>

 	<!-- TD 2 begins -->
 		<td valign="top">
 		<p><h4>Perspective Icons</h4></p>

 	<!-- TD 2 : Table 1 begins -->
 		<table width="500" cellspacing="2" cellpadding="2" border="0">
 			<tr valign="top">
 				<td></td>
 			  <td width="300"><strong>Item</strong></td>
 			  <td width="200"><strong>Positioning and Spacing</strong></td>
 			</tr>
 			<tr valign="top">
 				<td><strong>A</strong></td>
 			  <td>Perspective bar</td>
 			  <td>27 pixels wide</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>B</strong></td>
 			  <td>Between left margin and icon</td>
 			  <td>5 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>B</strong></td>
 			  <td>Between icon and right margin</td>
 			  <td>6 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>B</strong></td>
 			  <td>Between top of perspective section and first icon</td>
 			  <td>3 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>B</strong></td>
 				<td>Between icon and hard rule</td>
 				<td>6 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>C</strong></td>
 			  <td>Between hard rule and top of icon</td>
 			  <td>6 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>D</strong></td>
 			  <td>Vertically between icons</td>
 			  <td>6 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>E</strong></td>
 			  <td>Between icon and hard rule</td>
 			  <td>6 pixels</td>
 			</tr>
 		</table>
 		<!-- TD 2 : Table 2 begins -->
 	<h4>Fastview Icons</h4>
 		<table width="500" cellspacing="2" cellpadding="2" border="0">
 			<tr valign="top">
 				<td></td>
 			  <td width="300"><strong>Item</strong></td>
 			  <td width="200"><strong>Positioning and Spacing</strong></td>
 			</tr>
 			<tr valign="top">
 				<td><strong>D</strong></td>
 			  <td>Vertically between icons (same as perspective icons)</td>
 			  <td>6 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>E</strong></td>
 			  <td>Between icon and hard rule</td>
 			  <td>6 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>F</strong></td>
 			  <td>Between left margin and icon</td>
 			  <td>5 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>F</strong></td>
 			  <td>Between top of fastview section and first icon</td>
 			  <td>3 pixels</td>
 			</tr>
 			<tr valign="top">
 				<td><strong>F</strong></td>
 			  <td>Between icon and right margin</td>
 			  <td>6 pixels</td>
 			</tr>
 		</table>
 	</td>
 </tr>
 </table>


 		<h4>4. Tree View icons</h4>
 		<p class="sub">(Model Object Icons)</p>

 		<IMG hspace="40" height="190" alt="treeview specification" src="images/treeview_specs.gif" border=0 >
 		<br>
 		<br>
 		<table border="0" cellspacing="2" cellpadding="4">
 		<tr>
 		<td rowspan="8" width="40px"></td>
 		<td></td>
 		  <td width="350"><strong>Item</strong></td>
 		  <td width="200"><strong>Positioning and Spacing</strong></td>
 		</tr>
 		<tr>
 		<td><strong>A</strong></td>
 		  <td>Between &ldquo;+/-&rdquo; widget and left of window</td>
 		  <td>4 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>A</strong></td>
 		  <td>Between &ldquo;+/-&rdquo; widget and top of window</td>
 		  <td>4 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Between top of window and first icon</td>
 		  <td>0 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Vertically between icons</td>
 		  <td>0 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Between horizontal treeview branch and icon</td>
 		  <td>0 pixels</td>
 		</tr>
 		<tr>
 		<td><strong>B</strong></td>
 		  <td>Between icon and text label</td>
 		  <td>3 pixels</td>
 		</tr>
 		<tr valign="top">
 		<td><strong>C</strong></td>
 		  <td>Text is nested within the text label</td>
 		  <td width="200">3 pixels each on left and top, 2 pixels on right, 4 pixels on bottom (length varies)</td>
 		</tr>
 		</table>
 	<br>

 <!-- Icon Specifications / Icon Overlays -->
 <br>
 <h3><a NAME="IconSpecsOvr_VDG">Icon Overlays</a></h3>
 <p>
 	As stated under Icon Size &amp; Placement, all overlays are consistently the same size: 7 x 8 pixels.
 	An additional white border keyline is included on Project Nature and Java Overlay types to visually separate them
 	from the underlying Model Object icon. The keyline location varies depending on the overlay's placement on the
 	underlying icon.
 </p>

 <strong>Project Nature Overlay</strong>
 	<p>The project nature overlays are displayed in the Navigator and the Package views.
 	They are completely superimposed on the model object at the top right corner
 	of the 16 x 16 icon space.
 	</p>
 	<p>
 	Only a few project nature overlay icons have been created to prevent crowding in the interface.
 	Project nature overlays quickly identify the various <strong>types</strong> of projects that can be contained in
 	the Navigator and mirroring views.
 	</p>
 	<p>
 	The white keyline border is applied around the image to enhance legibility.
 	</p>
 	<p>
 	<img src="images/ovr_projectnature.gif" hspace="40" width="180" height="180"
 	alt="size and location of the project nature overlay in the upper right corner of the model object icon" border="0">
 	&nbsp;&nbsp;&nbsp;
 	<img src="images/ovr_projectnature_sample.gif" hspace="40" width="180" height="180"
 	alt="sample of a project nature overlay in the upper right corner of the model object icon"
 	border="0">
 	</p>

 <br>
 <strong>Auxiliary Overlay</strong>
 	<p>The auxiliary overlays are displayed in all tree views. This type of overlay is completely superimposed
 	on the model object at the bottom left corner of the 16 x 16 icon space.</p>
 	<p><img src="images/ovr_auxiliary.gif" hspace="40" width="180" height="180" alt="" border="0"></p>
 	<p>
 	The auxiliary overlay quickly identifies the <strong>status</strong> of an object. Examples of auxiliary overlays are
 	<em>warning</em>, <em>error</em>, <em>failure</em>, and <em>success</em>.
 	</p>

 <br>
 <strong>Java Overlay</strong>
 <p>The Java overlays are displayed in the Outline, Hierarchy, and Package views.
 The Java overlays are appended to the model object icon, so they extend
 the 16x16 icon space. They are placed to the right of a model object icon, overlapping the 16x16 model object space by 3 pixels.
 A maximum of 3 java overlays can be put on the model object.</p>
 <p>The order in which an overlay appears depends on the order in which it has been assigned. In designing Java overlays, it is
 important to make sure the base object icon can support the addition of overlays without compromising readability. Note that there
 are two Java overlays that always display at the bottom right corner &mdash; 'C' position in the layout shown below &mdash; of the
 model object:
 <img src="images/synch_co.gif" width="7" height="8" alt="" border="0">
 <strong>synchronized</strong> (method) and <img src="images/run_co.gif" width="7" height="8" alt="" border="0">
 <strong>run</strong> (class).</p>
 <p><img src="images/ovr_java.gif" hspace="40" width="276" height="218"
 alt="size and location of the java overlays to the right of the model object icon" border="0">
 &nbsp;&nbsp;&nbsp;
 <img src="images/ovr_java_sample1.gif" hspace="40" width="276" height="218"
 alt="sample of java overlays to the right of the model object icon" border="0">
 </p>

 	<p>
 	Java overlays identify <strong>attributes</strong> of an object. Examples of Java overlays are
 	<em>static</em>, <em>final</em>, <em>abstract</em>, and <em>synchronized</em>.
 	</p>

 <p><strong>Note:</strong> In the Hierarchy and Outline views, the Java overlays are appended to the right of the model object
 as shown, but in the Package view they are stacked over the model object.</p>

 <br>
 <strong>Version Control Overlay</strong>
 	<p>Version control overlays are displayed in the Navigator view and in the Structure View of the Merge Editor in CVS.
 	When they are displayed in the Navigator view, the overlay is completely superimposed on the model object at the right
 	of the 16 x 16 icon space.
 	</p>

 	<p><img src="images/ovr_versioncontrol.gif" hspace="40" width="180" height="180"
 	alt="size and location of the version control overlays in the Navigator view in the lower right corner of the model object icon"
 	border="0"></p>

 	<p>When the version control overlays are displayed in the Structure View of the Merge Editor in CVS, they are
 	appended to the model object, so they extend the 16x16 space. They are placed to the right of a model object icon,
 	overlapping the 16x16 model object space by 3 pixels.
 	In CVS there is a maximum of 2 overlays on the right of the object.</p>

 	<p><img src="images/ovr_versioncontrol_cvs.gif" hspace="40" width="216" height="209"
 	alt="size and location of the version control overlays in the Structure view of the Merge Editor in CVS at the right of the model object icon"
 	border="0">&nbsp;&nbsp;&nbsp;
 	<img src="images/ovr_versioncontrol_cvs_samp.gif" hspace="40" width="216" height="209"
 	alt="sample of the version control overlays in the Structure view of the Merge Editor in CVS at the right of the model object icon"
 	border="0">
 	</p>
 <br>

 	<p>
 	Version control overlays identify a <strong>transition-state</strong> of an object. Examples of CVS overlays are
 	<em>incoming</em>, <em>outgoing</em>, <em>in conflict</em>, <em>added</em>, <em>deleted</em>, and <em>changed</em>.
 	</p>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.8</font></b>
 <blockquote><font color="#09448D">Follow the positioning guidelines for the different types of icons for optimal alignment
 of these elements relative to one another.</font></blockquote></p>

 <!-- ICON SPECIFICATION SECTION ENDS -->


 <!-- WIZARD SPECIFICATION SECTION BEGINS -->
 <!-- Wizard Specifications / Wizard Palette -->
 <br>
 <h3><a NAME="WizSpecsPal_VDG">Wizard Palette</a></h3>
 <p>The Wizard Palette section shows the
 the special blue 183 color palette you will need to create your wizard graphics.
 <br>
 Eclipse style wizard banner graphics should be designed using a special blue 183 color palette,
 as shown below.</P>
 <p>
 <img src="images/wizban183.gif" hspace="40" width="194" height="145" alt="" border="0">
 </p>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.9</font></b>
 <blockquote><font color="#09448D">Use the Eclipse special blue 183 color palette for creating wizard graphics.</font></blockquote></p>
 <hr>

 <!-- Wizard Specifications / Wizard Size & Placement -->
 <br>
 <br>
 <h3><a NAME="WizSpecsSize_VDG">Wizard Size &amp; Placement</a></h3>
 <p>The Wizard Sizing section gives the sizing guidelines for
 creating wizard banner graphics.
 <br>
 All wizard banner graphics are designed to fit within a specified screen space that is
 75 pixels wide x 58 pixels high, in the top, right corner of the wizard.
 </p>

 <br>
 <br>
 <p>
 <img src="images/wizban.gif" hspace="40" width="395" height="175" alt="" border="0">
 </p>
 <br>
 <br>
 <p>
 The actual size of each wizard banner graphic will vary depending on the elements involved, but should not exceed
 55 pixels wide x 45 pixels high.
 </p>
 <p>
 Within the wizard banner space allocation,
 there is no firm rule for where to place the wizard banner graphic.
 Generally, the graphic is centered vertically,
 and off-center to the left horizontally.
 </p>
 <br>
 <br>
 <img src="images/wizbans.gif" hspace="40" width="366" height="140" alt="" border="0">
 <br>
 <br>
 <br>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.10</font></b>
 <blockquote><font color="#09448D">Follow the specific size specifications for wizard graphics.</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.11</font></b>
 <blockquote><font color="#09448D">Cut the wizard graphics with the specific placement shown to ensure alignment
 in the wizard banner area.</font></blockquote></p>
 <!-- WIZARD SPECIFICATION SECTION ENDS -->


 <!-- IMPLEMENTATION CONVENTIONS SECTION BEGINS -->

 <!-- Implementation Ready -->
 <h3><a NAME="ConsistencyImp_VDG">Implementation Conventions</a></h3>
 <p>
 Eclipse provides a set of directory names and structure for storing and accessing user interface graphics
 easily in any plug-in. This section describes the naming conventions and directory path used in Eclipse. If followed,
 the predefined directory names and path allow for the icon and wizard graphic files to be implemented directly into the
 plug-in structure without any need for modifications.
 </p>
 <p>
 From icon request to delivery, the naming and structure is the same. If you use a different user interface
 directory name or more than one directory to store graphics than that specified at request time, notify your visual
 design contact of these changes so that they can maintain a parallel system. Further, keeping the number of directories
 in which you store your graphics to a minimum, will reduce unnecessary duplication of graphics and ease resource
 management issues considerably.
 </p>

 <br>

 <h4>Directory Names and Structure</h4>
 <p>
 Once your icons have been conceptualized, designed, approved and cut, they are stored using the directory naming
 convention and structure described below.
 </p>
 <ol type="A">
 <li>The name of the first level directory refers to the Eclipse platform: Icons used in an Eclipse plug-in are
 called <strong>org.eclipse.pluginname.ui_0.0.0</strong>. Where <strong>pluginname</strong> is substituted with the name
 of the plug-in and <strong>_0.0.0</strong> is substituted with the Eclipse version number, for example,
 <strong>org.eclipse.debug.ui_2.1.0</strong>
 <br>
 <br>
 </li>
 <li>Each plug-in that manages user interface elements for a tool set contains a second level directory
 called <strong>icons</strong>.
 <br>
 <br>
 </li>
 <li>
 Within the <strong>icons</strong> directory, there are separate folders with names that indicate the state, type and
 size of the icons, as follows:
 <ol>
 <li>
 The first letter of the folder name indicates the icon state. The letter <strong>c</strong> for color,
 <strong>d</strong> for disabled, and <strong>e</strong> for enabled.
 <br>
 </li>
 <li>The next 3 to 6 letters signify the icon type: toolbar (tool), local toolbar (lcl),
 view or perspective (view), model object (obj), overlay (ovr), wizard banner (wizban).
 <br>
 </li>
 <li>The last two digits of the folder name indicate the size of the icons within. Usually it
 will be <strong>16</strong> (to indicate the 16 pixel by 16 pixel size), but there might be others
 (for example, <strong>32</strong> would indicate the 32 x 32 size) depending on the plug-in requirements.
 </li>
 </ol>
 </li>
 </ol>
 <p>The following image shows a complete directory structure for a plug-in.</p>
 <p><img src="images/impready_folderstructure.gif" hspace="40" width="483" height="230"
 alt="Image showing the complete directory structure for user interface graphics a plug-in, as described in text above"
 border="0">
 </p>

 <p><strong>NOTE:</strong>&nbsp;
 <ol>
 <li>
 For many plug-ins, inside the <strong>icons</strong> directory, there is a folder called "<strong>full</strong>"
 which then contains these icon type folders. This <strong>full</strong> folder is being phased out of the icon directory
 structure for new plug-ins. The structure shown above is the recommended icon directory structure.
 </li>
 <li>
 Your plug-in may not require all types of icons shown in the sample. The sample illustrates the complete set of icon types
 that you may need in your plug-in. In addition, there are sometimes exceptions to this list of types in plug-ins that have
 a special type of icon that is not covered by this standard set. This is rare, however, and we encourage you to get to know
 the different types and their respective states, and use the structure as shown.
 </li>
 <li>When an icon has multiple states, the file name is the same across each of the active (color), enabled, and disabled
 state folders. Because of this organization, using the states provided is important, and will prevent you from having
 to rename the states of your icons if all were stored in the same folder.
 </li>
 </ol>
 </p>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.12</font></b>
 <blockquote><font color="#09448D">Follow the predefined directory structure and naming convention.</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.13</font></b>
 <blockquote><font color="#09448D">Keep the original directory names provided.</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.14</font></b>
 <blockquote><font color="#09448D">Minimize duplication of graphics within a plugin by keeping all graphics in one, or few, first level user interface directories.</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.15</font></b>
 <blockquote><font color="#09448D">Use the active, enabled, and disabled states provided.</font></blockquote></p>
 <hr>

 <br>
 <h4>File Names</h4>
 <p>Establishing file names before the icons are designed will help ensure appropriately descriptive names for the concepts
 they represent, and may prevent misuse of icons for purposes not intended and duplicate file names. If the names are well
 considered in advance, you will appreciate being able to quickly make the distinction between icon types and find concepts
 more readily, especially as the volume of your graphic resources increases.
 </p>

 <h4>Suggestions for File Name Suffixes</h4>
 <p>File suffixes are useful for making the distinction between types of user interface elements. They can be used to denote
 the location or function of an icon or wizard graphic. The following table shows how suffixes are being used for image file
 names in Eclipse:
 </p>
 <table cellspacing="2" width="100%" cellpadding="2" border="0">
 <tr bgcolor="#c0c0c0">
   <td><strong>Filename Suffix</strong></td>
 	<td><strong>Used for icons with the following function or location:</strong></td>
   <td><strong>Icon Type and Location</strong></td>
 </tr>
 <tr valign="top" bgcolor="#e4e4e4">
   <td>*_wiz.gif</td>
 	<td>invoke a wizard, or are graphics within a wizard</td>
   <td>Wizard banner graphics: used in wizard dialog windows.<br>
 	Wizard icons: used on wizard toolbars.</td>
 </tr>
 <tr valign="top">
   <td>*_exec</td>
 	<td>invoke executable files</td>
   <td>Toolbar icons: used in cascading menus, and global toolbars.</td>
 </tr>
 <tr valign="top" bgcolor="#e4e4e4">
   <td>*_edit</td>
 	<td>are in an editor view</td>
   <td>Toolbar icons: used in cascading menus, and global toolbars.</td>
 </tr>
 <tr valign="top">
   <td>*_nav</td>
 	<td>are in a navigator view</td>
   <td>Toolbar icons: used in cascading menus, and global toolbars.<br>
 	Local toolbar icons: found on the far right of the title area of a view. <br>
 	View and perspective icons: found in the top, left corner of a view. </td>
 </tr>
 <tr valign="top" bgcolor="#e4e4e4">
   <td>*_misc</td>
 	<td>do no fit into any of the other categories</td>
   <td>Toolbar icons: used in cascading menus, and global toolbars.<br>
 	View and perspective icons: found in the top, left corner of a view.</td>
 </tr>
 <tr valign="top">
   <td>*_tsk</td>
 	<td>represent tasks that user can do</td>
   <td>Local toolbar icons: found on the far right of the title area of a view.<br>
 	Overlay icons: placed on top of a model object icon to indicate a change in condition.<br>
 	Object icons: used in the tree view, list view, and properties view.<br>
 	View and perspective icons: found in the top, left corner of a view.
 	</td>
 </tr>
 <tr valign="top" bgcolor="#e4e4e4">
   <td>*_mode</td>
 	<td>toggles the working mode of the view</td>
   <td>Local toolbar icons: found on the far right of the title area of a view.
 	</td>
 </tr>
 <tr valign="top">
   <td>*_menu</td>
 	<td>are found in a menu</td>
   <td>Local toolbar icons: found on the far right of the title area of a view.
 	</td>
 </tr>
 <tr valign="top" bgcolor="#e4e4e4">
   <td>*_ps</td>
 	<td>are found in a property sheet</td>
   <td>Local toolbar icons: found on the far right of the title area of a view.<br>
 	View and perspective icons: found in the top, left corner of a view.
 	</td>
 </tr>
 <tr valign="top">
   <td>*_obj</td>
 	<td>represent model objects</td>
   <td>Model object icons: used in the tree view, list view, and properties view.</td>
 </tr>
 <tr valign="top" bgcolor="#e4e4e4">
   <td>*_pal</td>
 	<td>are model object icons on object palettes</td>
   <td>Model object icons: used on object palettes</td>
 </tr>
 <tr valign="top">
   <td>*_co</td>
 	<td>is for commands that engage the system, e.g. build command</td>
   <td>Toolbar icons: used in cascading menus, and global toolbars.<br>
 	Local toolbar icons: found on the far right of the title area of a view.
 	</td>
 </tr>
 <!-- Use the following table row if the last row of data has a white background. It provides
 a line to define the table information from the rest of the text. If the last row of data has
 the dark gray background, you don't need it, so comment it out. -->
 <tr height="1" valign="top" bgcolor="#e4e4e4">
   <td></td>
 	<td></td>
   <td></td>
 </tr>
 </table>

 <br>
 </td>
 </tr>
 </table>

 <p>To aid you in choosing your file names, we offer the following guidelines:</p>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.16</font></b>
 <blockquote><font color="#09448D">Abbreviate file name instead of using the full icon name,
 e.g. New Interface becomes "newint".</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.17</font></b>
 <blockquote><font color="#09448D">Use lower case characters in your file names, e.g. DTD becomes "dtd".</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.18</font></b>
 <blockquote><font color="#09448D">Use 10 characters or less in your file names if possible (underscores count as a character).</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.19</font></b>
 <blockquote><font color="#09448D">Use a file name suffix that describes its location or function in the tool,
 e.g. newint_wiz.</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.20</font></b>
 <blockquote><font color="#09448D">Use transparent *.gif format for all user interface icons and wizard graphics,
 unless the context requires a different file format.</font></blockquote></p>
 <hr>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16">
 <b><font color="#09448D">Guideline 2.21</font></b>
 <blockquote><font color="#09448D">Keep the original file names provided.</font></blockquote></p>

 <!-- IMPLEMENTATION CONVENTIONS SECTION ENDS -->
 <!-- END OF VISUAL DESIGN CONTENT -->

 <br>
 <h2>
 <a NAME="Component Development"></a>Component Development</h2>

 <h3>
 <a NAME="Commands"></a>Commands</h3>
 A command, which is invoked by a user to carry out some specific functions, may appear as an item in a menu, or an item in a toolbar.&nbsp;
 In reflection of this, it has attributes for the menu or tool item label,
 tooltip, and image.
 <p>As a plug-in developer, you can contribute commands to the window menu
 bar and toolbar, or to individual views and editors.&nbsp; Contribution
 to the window is performed using an action set, a set of task oriented
 commands which the user can show or hide.&nbsp; Contribution to a view or
 editor is performed using individual command.
 <p>Here is an illustration of the main areas of contribution.

 <p><img src="images/actionExamples.gif" hspace="40" height="664" width="789">

 <p>In this section we'll look at general command guidelines.&nbsp; For information
 on window, view, or editor specific guidelines, see <a href="#Windows">Windows</a>,
 <a href="#Views">Views</a>,
 and <a href="#Editors">Editors</a>.
 <h4>
 Appearance</h4>
 Each  command must have a label, tool tip, and image.&nbsp; If the command
 appears in a toolbar, the command image will be displayed on all platforms.&nbsp;
 If the command appears in a menu, the image will only be displayed on some
 platforms, such as Windows&reg; 2000.&nbsp; The label and tool tip should use
 Headline style capitalization, as defined in General UI Guidelines.
 <p>Each command must provide one full color image.&nbsp; This image will
 be displayed if the mouse is placed over the command.&nbsp; It will also
 be used to generate the enabled, disabled, and pressed images which appear
 in normal command use.&nbsp; Commands which are contributed in code also
 have the option to define explicit images for enabled, disabled, and roll
 over.&nbsp; This option can be used for greater control over image appearance.
 <p>The following snapshot shows the valid use of Headline capitalization
 in a toolbar.
 <p><img src="images/tooltipCaps.gif" height=141 width=244>
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 3.1</font></b>
 <blockquote><font color="#09448D">Each command must have a label, tool tip,
 and full color image.&nbsp; The label and tool tip must use Headline style
 capitalization.</font></blockquote>
 <hr>
 <p>
 The tool tips for a  command should describe the <i>behavior which occurs</i>
 if the command is invoked, independent of the current state.&nbsp;For push buttons, the label should decribe the result of users pushing the button.
 For toggle buttons, it should describe its effect when the item is toggled on, and the label should not change depending on the state of the button. In Eclipse version 2.1, it is recommended that the tool tip for a command uses the same text as that for the command label.
 For instance, in the following snapshot
 the behavior of the Show Type Hierarchy button is shown using one tool tips text.

 <p><img src="images/goodTooltips.gif" hspace="40" height=169 width=213>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 3.2</font></b>
 <blockquote><font color="#09448D">The command tooltip should describe the
 result of the command, not the current state of the command. Use the text same as that for the command label.</font></blockquote>
 <hr>
 <p>
 For consistency, any command which has a similar behavior to existing commands
 in the workbench, should adopt the same terminology.
 <p>When creating a resource, the term "New" should be used in a command
 or wizard.&nbsp; For instance, "New File", "New Project" and "New Java
 Class".&nbsp; The term "Delete" should be used when deleting an existing
 resource.
 <p>When creating an object inside a resource (e.g., a tag in an XML file;
 a method or field in a Java class), the term "Add" should be used; the
 user is adding something to an existing resource.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 3.3</font></b>
 <blockquote><font color="#09448D">Adopt the labeling terminology of the
 workbench for New, Delete and Add commands.</font></blockquote>
 <hr>
 <p>

 <h4>
 Enablement</h4>
 A command should only be enabled if it can be completed successfully.&nbsp;
 If this is not the case, the command should be disabled.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 3.4</font></b>
 <blockquote><font color="#09448D">A command should only be enabled if it
 can be completed successfully.</font></blockquote>
 <hr>
 <p>
 Command enablement should be quick to calculate.&nbsp; If it is too expensive
 to calculate the enablement of a command, the command should be optimistically
 enabled.&nbsp; If the command is invoked, it should calculate the real enablement,
 and show a dialog to the user if it is not available.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 3.5</font></b>
 <blockquote><font color="#09448D">Command enablement should be quick.&nbsp;
 If command enablement cannot be quick, enable the command optimistically
 and display an appropriate message if the command is invoked, but cannot
 be completed.</font></blockquote>

 <p>

 <h3>
 <a NAME="Dialogs"></a>Dialogs</h3>
 A dialog is used for modal interaction with the user.&nbsp; It can be used
 to solicit information, or provide feedback.
 <br>&nbsp;
 <h4>
 Initialization</h4>
 When a dialog first opens, the initial focus should be given to the first
 control where information is required from the user.&nbsp; This control
 can be determined by the tab order of controls until a control is found
 where information is required.&nbsp; If the dialog provides simple feedback,
 or requires simple confirmation from the user, the initial focus may also
 be assigned to the default button.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 4.1</font></b>
 <blockquote><font color="#09448D">When a dialog opens, set the initial
 focus to the first  input control in the container. If there are no input controls, the initial focus should
 be assigned to the default button.</font></blockquote>
 <hr>
 <p>

 <h4>
 Multiple Item Selection</h4>
 Slush Bucket widgets (also known as the Twin Box design) should flow from
 the left to the right with the source objects on the left and selected
 files on the right.
 <p>Slush Buckets should also have the following control buttons, in this
 order, for moving objects from the source the selected buckets.
 <br>&nbsp;
 <table class="indent" border="1" cellspacing="0" cellpadding="3">
 <tr>
 <td><b>Button</b></td>

 <td><b>Function</b></td>
 </tr>

 <tr>
 <td>></td>

 <td>Add whatever is selected on the left to the right</td>
 </tr>

 <tr>
 <td>&lt;</td>

 <td>Remove selected items from the right</td>
 </tr>

 <tr>
 <td>>></td>

 <td>Add all (whether they are selected or not)</td>
 </tr>

 <tr>
 <td>&lt;&lt;</td>

 <td>Remove&nbsp; all</td>
 </tr>
 </table>

 <p><img src="images/slushBucket.gif" hspace="40" height=278 width=533>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 4.2</font></b>
 <blockquote><font color="#09448D">Slush Bucket widget (or Twin Box) should
 flow from left to right with the source objects on the left hand side.
 It should have the >, &lt;, >>, &lt;&lt; control buttons in this order.</font></blockquote>

 <p>

 <h3>
 <a NAME="Wizards"></a>Wizards</h3>
 In Eclipse, a wizard is commonly used for the creation of new resources,
 resource import, or resource export.&nbsp; It can also be used for the
 execution of any task involving a sequential series of steps.&nbsp; A wizard
 should be used if there are many steps in the task, and they must be completed
 in a specific order.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.1</font></b>
 <blockquote><font color="#09448D">Use a wizard for any task consisting
 of many steps, which must be completed in a specific order.</font></blockquote>
 <hr>
 <p>

 <h4>
 Appearance</h4>
 At the top of each wizard is a header, containing a banner graphic and
 a text area.&nbsp; The banner graphic contains an image representing the
 wizard task, and should be created with a white to blue, gray scale palette
 for consistency with other banners in Eclipse.&nbsp; These colors also
 avoid distracting the user from the important fields of the wizard.&nbsp;
 The text area is used to prompt the user for information which is absent,
 and display error messages if information is invalid.&nbsp; The presence
 of the header, with banner graphic and text area, creates a more polished
 feel, and greater perception of quality to the wizard.
 <p>At the bottom of each wizard, a Back, Next, Finish, and Cancel button
 should appear.
 <p><img src="images/wizardAppearance.gif" hspace="40" height=390 width=500>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.2</font></b>
 <blockquote><font color="#09448D">Each wizard must contain a header with
 a banner graphic and a text area for user feedback.&nbsp; It must also
 contain Back, Next, Finish, and Cancel buttons in the footer.</font></blockquote>
 <hr>
 <p>

 <h4>
 Initialization</h4>
 When a wizard first opens, the focus should be placed in the first field
 requiring information (see Guidelines 3.1).&nbsp; The header should be
 used to prompt the user for the first piece of required information.
 <p><img src="images/goodWizardInit.gif" height=122 width=570>
 <p>It is not appropriate to display an error message.&nbsp; At this point,
 the user hasn't done anything yet.
 <p><img src="images/badWizardInit.gif" height=124 width=576>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.3</font></b>
 <blockquote><font color="#09448D">Start the wizard with a prompt, not an
 error message.</font></blockquote>
 <hr>
 <p>
 The initial state of the wizard should be derived from the context where
 it is opened.&nbsp; For instance, in the New File wizard, the current workbench
 selection is examined.&nbsp; If it points to a valid project or folder,
 the wizard will pre-populate the parent field with the parent project or
 folder name, and put cursor focus in the next field requiring user input.&nbsp;
 If the user's selection does not point to a valid parent project or folder,
 the wizard will not pre-populate the folder name. Instead, it will leave
 the field blank and put the cursor focus in the field.&nbsp;&nbsp; When
 the user's selection is on a file, a wizard may also go through these calculations
 using the parent folder or project of the file.
 <p><img src="images/wizardFieldPopulation.gif" height=300 width=533>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.4</font></b>
 <blockquote><font color="#09448D">Seed the fields within the wizard using
 the current workbench state.</font></blockquote>
 <hr>
 <p>

 <h4>
 Validation of Data</h4>
 Information validation within a wizard should be done in tab order.&nbsp;
 If the first required field is empty, an informative prompt should be shown
 in the text area, directing the user to fill in the field.&nbsp; If the
 first required field is in error, an error message should be shown in the
 text area.&nbsp; If the first required field is valid, check the next field,
 and so on.&nbsp; The text area should not be used to display more than
 one prompt or error at a time.
 <p>If dialog information is absent or invalid, the Next or Finish buttons
 should be disabled until the situation is resolved.&nbsp; When resolution
 occurs, and all of the information has been provided, the Next or Finish
 buttons may be enabled.
 <p><img src="images/wizardErrorMsgs.gif" height=527 width=540>
 <p>Error messages should only be displayed when user input is invalid.
 <p><img src="images/wizardErrorMsgs2.gif" height=199 width=454>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.5</font></b>
 <blockquote><font color="#09448D">Validate the wizard data in tab order.&nbsp;
 Display a prompt when information is absent, and an error when information
 is invalid.</font></blockquote>
 <img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.6</font></b>
 <blockquote><font color="#09448D">Only enable the Next / Finish buttons
 if all required information in the dialog is present and valid.</font></blockquote>
 <hr>
 <p>
 The error messages in a wizard should be intended for the end user, not
 the developer.&nbsp; With this in mind, message IDs should never be presented
 as part of the error text in the wizard's header area.
 <p><img src="images/wizardMsgs.gif" height=98 width=543>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.7</font></b>
 <blockquote><font color="#09448D">Remove all programming message ID's from
 wizard text.</font></blockquote>
 <hr>
 <p>

 <h4>
 Browse Buttons</h4>
 An edit field and "Browse..." button combination should be used whenever
 an existing object is referenced within a wizard.&nbsp; The edit field
 is used for direct input of the existing object, and the Browse button
 is used to browse and select the object from a list of all possible choices.
 <p>For instance, in the New Java Class wizard, a "Browse..." button is
 placed beside the "Super Class" edit field.&nbsp; If the browse button
 is pressed, a Browse Dialog will appear, and the user can select a super
 class.&nbsp; This pattern should be used whenever a link will be established
 between a new object and an old one.&nbsp; The "Browse..." button should
 be located to the right of the edit field.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.8</font></b>
 <blockquote><font color="#09448D">Use a Browse Button whenever an existing
 object is referenced in a wizard.</font></blockquote>
 <hr>
 <p>
 In the Browse Dialog, invalid choices should not appear.&nbsp; When the
 dialog is closed, and focus returns to the parent control, refresh the
 enablement state of controls within the dialog.&nbsp; In particular, refresh
 the enablement of Next, Finish, and OK buttons.
 <p>An example of valid and invalid filtering is shown in the following
 snapshot.
 <p><img src="images/folderSelection.gif" height=1220 width=611>
 <br>&nbsp;
 <h4>
 Wizard Completion</h4>
 The New Resource and Import Wizards commonly create new files, folders,
 and projects within the workbench.&nbsp; If a single file is created, the
 wizard should open the file in an editor in the active page.&nbsp; If more
 than one file is created, open the most important, or central file.&nbsp;
 This makes it easier to modify and save the file.
 <p>Have a readme.html file for every example project, and open that
 readme.html automatically upon project creation.&nbsp; This will give users
 an immediate overview of the example: what it does, prerequisites, limitations,
 steps to take, and so on.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.9</font></b>
 <blockquote><font color="#09448D">If a new file is created, open the file
 in an editor.&nbsp; If a group of files are created, open the most important,
 or central file in an editor. Open the readme.html file upon creation of
 an example project.</font></blockquote>
 <hr>
 <p>
 If a new project is created, the wizard should change the active perspective
 within the workbench to one which is appropriate for the new project type.
 In Eclipse v2.1, users are prompted to confirm the switch to the preferred perspective when creating a new project.
 To avoid loss of context, plug-ins should use this, and not automatically switch without prompting.
 If users want to switch automatically in the future, they can choose &quot;Do not show this message again&quot; in
 the confirmation dialog.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.10</font></b>
 <blockquote><font color="#09448D">If a new project is created, prompt users and change the
 active perspective to suit the project type.</font></blockquote>
 <hr>
 <p>
 In either case, where a file, folder, or project is created, the wizard
 should select and reveal the new object in the appropriate view.&nbsp;
 This provides concrete evidence to the user that, yes, the new object was
 created and now exists.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.11</font></b>
 <blockquote><font color="#09448D">If a new object is created, select and
 reveal the new object in the appropriate view.</font></blockquote>
 <hr>
 <p>
 In many situations, the creation of a resource may involve the creation
 of a project or folder to contain the resource.&nbsp; If the containing
 project or folder can be created from within the wizard (with a very reasonable
 set of defaults), the wizard should allow it. If the creation of such resources
 requires detailed user interaction in order for parent project or folder
 to be set up correctly, the wizard should not attempt to do this. Instead,
 the wizard error text should instruct the user that "The specified project
 does not exist".
 <p>The EAR Import wizard in IBM's WebSphere Studio is an example where allowing the user to specify
 the name of the parent project in place makes for a much more usable interaction.
 In this case, based on the user provided name, the wizard goes off and
 creates not only the EAR project itself, but also any web projects, etc.,
 that may be needed as well.
 <p><img src="images/goodParentCreation.gif" height=299 width=506>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.12</font></b>
 <blockquote><font color="#09448D">Create folder objects in a wizard if
 reasonable defaults can be defined.</font></blockquote>
 <hr>
 <p>

 <h4>
 Terminology</h4>
 Within a creation wizard, if the item being created must be a Project (not
 a folder below a project), the term "Project" should be used.&nbsp; If it can be a folder below the project, the term
 "Folder" should be used.&nbsp; In addition,  use the &quot;name&quot; suffix (uncapitalized) and no other prefix  for the  input field label. For example, use &quot;Project name&quot; or &quot;Folder name&quot; but not &quot;Project Name&quot; or &quot;Server Project name&quot;.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 5.13</font></b>
 <blockquote><font color="#09448D">Use the term "Project name" for the input field label when the
 item must be a Project; otherwise, use the term "Folder name". Do not qualify
 the term.</font></blockquote>

 <p>

 <h3>
 <a NAME="Editors"></a>Editors</h3>
 An editor is a visual component within a workbench page. It is
 <FONT color="#000000">used to interact with the primary content, which
 may be a document or data object.&nbsp; In every case, this content is
 the primary focus of attention and a reflection of the primary task.</FONT>
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.1</font></b>
 <blockquote><font color="#09448D">Use an editor to edit or browse a file,
 document, or other primary content.</font></blockquote>
 <hr>
 <p>
 Modifications made in an editor follow an open-save-close lifecycle model.&nbsp;
 When an editor first opens, the editor contents should be unmodified (clean).&nbsp;
 If the contents are modified, the editor should communicate this change
 to the platform.&nbsp; In response, an asterisk will appear in the editor
 tab.&nbsp; The modifications should be buffered within the edit model,
 until such a time as the user explicitly saves them.&nbsp; At that point,
 the modifications should be committed to the model storage.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.2</font></b>
 <blockquote><font color="#09448D">Modifications made in an editor must
 follow an open-save-close lifecycle model.</font></blockquote>
 <hr>
 <p>
 An editor is document or input-centric.&nbsp; Each editor has an input,
 and only one editor can exist for each editor input within a page.&nbsp;
 This policy has been designed to simplify part management.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.3</font></b>
 <blockquote><font color="#09448D">Only one instance of an editor may exist,
 for each editor input, within a perspective.</font></blockquote>
 <hr>
 <p>
 In addition, it should be possible to open a separate instance of an editor
 for each different input.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.4</font></b>
 <blockquote><font color="#09448D">It must be possible to open a separate
 instance of an editor for each different input.</font></blockquote>
 <hr>
 <p>

 <h4>
 Appearance</h4>
 The editor should be labeled with the name of the resource being edited;
 not with the name of the editor.
 <p><img src="images/editorTitles.gif" height=84 width=562>
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.5</font></b>
 <blockquote><font color="#09448D">The editor should be labeled with the
 name of the file, document, or input being edited.</font></blockquote>
 <hr>
 <p>
 If the editor contains more than one page, a tab control should be used
 for page activation.&nbsp; The use of this control is demonstrated by the
 plugin file and html editors.
 <p>Tab labels should be kept to one word, and two words at most.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.6</font></b>
 <blockquote><font color="#09448D">In multipage editors, use a tab control
 for page activation.Tab labels should be kept to one word, and two words
 at most.</font></blockquote>
 <hr>
 <p>

 <h4>
 Menus</h4>
 An editor may contribute items directly to the window menu bar.&nbsp; All
 of the commands available in the editor should be displayed in the window
 menu bar, for accessibility and clarity.
 Exceptions are for the obvious commands, e.g. basic navigations such as  next / previous character, line, word.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.7</font></b>
 <blockquote><font color="#09448D">All of the commands, except for the obvious commands, available in the editor
 should be added to the window menu bar.</font></blockquote>
 <hr>
 <p>
 The following format is recommended, to ensure consistency across Eclipse
 and better ease of use.
 <br>&nbsp;
 <table class="indent" border="1" cellspacing="0" cellpadding="3" width="80%" cols="4">
 <tr>
 <td>Edit</td>

 <td>(one or more editor specific menus)</td>

 <td>Window</td>
 </tr>

 <tr>
 <td>Add any object centric commands here</td>

 <td>(commands belong to the specific menus)</td>

 <td>Actions to control what you see in the editor.</td>
 </tr>
 </table>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.8</font></b>
 <blockquote><font color="#09448D">Use the standard format for editor contributions
 in the window menu bar.</font></blockquote>
 <hr>
 <p>
 The window menu bar contains a number of global commands, such as Cut, Copy,
 and Paste in the Edit menu.&nbsp; These commands target the active part,
 as indicated by a shaded title area.&nbsp; If these commands are supported
 within an editor, the editor should hook these window commands, so that
 selection in the window menu bar or toolbar produces the same result as
 selection of the same command in the editor.&nbsp; The editor should not
 ignore these commands, and contribute duplicate commands to the window menu
 bar or toolbar.
 <p>A complete list of the global commands is declared in the IWorkbenchActionConstants.java
 (see below).
 <p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /**</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * From IWorkbenchActionConstants.</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Standard global
 commands in a workbench window.</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final
 String [] GLOBAL_ACTIONS = {</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 UNDO,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 REDO,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 CUT,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 COPY,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 PASTE,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 PRINT,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 DELETE,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 FIND,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 SELECT_ALL,</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 BOOKMARK</tt>
 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; };</tt>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.9</font></b>
 <blockquote><font color="#09448D">If an editor has support for Cut, Copy,
 Paste, or any of the global commands, these commands must be executable from
 the same commands in the window menu bar and toolbar.</font></blockquote>
 <hr>
 <p>

 <h4>
 Toolbars</h4>
 An editor may contribute commands directly to the window toolbar.&nbsp;
 The toolbar is used to expose the
 <I>most commonly used</I>
 commands in an editor.&nbsp;
 Any command which appears in the toolbar must also appear in the menu, but
 there is no need to duplicate every command in the menu within the toolbar.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.10</font></b>
 <blockquote><font color="#09448D">Fill the editor toolbar with the most
 commonly used items in the view menu.</font></blockquote>
 <hr>
 <p>
 The use of a local toolbar within an editor is contrary to the design of
 the workbench.&nbsp; Within the workbench, the toolbar for an editor is
 shared with editors of the same type.&nbsp; This reduces the flash which
 occurs when you switch between editors, reduces the number of images and
 commands in the product, and creates a better feel of integration.
 <h4>
 Context Menus</h4>
 A context menu should be used for context sensitive interaction with the
 objects in an editor.&nbsp; If an object is selected in an editor, and
 the context menu is opened, the context menu should only contain commands
 which are appropriate for the selection.&nbsp; Commands which affect the
 presentation of the view should not appear in the context menu.
 <p>In a text editor, you may assume that there is only one type of selection:
 text.&nbsp; In this case, the contents of the context menu will remain
 consistent for any selection in the editor.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.11</font></b>
 <blockquote><font color="#09448D">Fill the context menu with selection
 oriented commands.</font></blockquote>
 <hr>
 <p>
 For consistency with other editors in Eclipse, each editor should adopt
 a common order for commands within the context menu.&nbsp; This format is
 shown in the following table.&nbsp; Within this table, each item represents
 a category of commands.&nbsp; The categories within the context menu should
 be kept distinct from one another through the use of separators.
 <br>&nbsp;
 <table class="indent" border="1" cellspacing="0" cellpadding="3" width="200" cols="1">
 <tr>
 <td>Undo / Redo</td>
 </tr>

 <tr>
 <td>Add</td>
 </tr>

 <tr>
 <td>Show In</td>
 </tr>

 <tr>
 <td>Cut Copy Paste</td>
 </tr>

 <tr>
 <td>Delete</td>
 </tr>

 <tr>
 <td>Other Plugin Additions</td>
 </tr>

 <tr>
 <td>Save</td>
 </tr>
 </table>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.12</font></b>
 <blockquote><font color="#09448D">Use the standard format for editor context
 menus.</font></blockquote>
 <hr>
 <p>
 For good spatial navigation, fill the context menu with a fixed set of
 commands for each selection type.&nbsp; Once the contents have been defined,
 the enablement state of each command should be determined using the selected
 object state.&nbsp; In doing so, you establish a consistency which makes
 the menu more predictable, and easier to navigate.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.13</font></b>
 <blockquote><font color="#09448D">Fill the context menu with a fixed set
 of commands for each selection type, and then enable or disable each to
 reflect the selection state.</font></blockquote>
 <hr>
 <p>
 One of the primary goals for the platform UI is extensibility.&nbsp; In
 fact, it is this extensibility which gives you the freedom to add new views,
 editors, perspectives, and actions to the platform.&nbsp; Of course, extensibility
 is a two way street.&nbsp; While you may wish to extend the platform, others
 may wish to extend your view or editor.&nbsp; It is common for one plug-in
 to add actions to the menu, toolbar, or context menu of an editor from
 another plugin.
 <p>In the platform, the menu and toolbar for an editor are automatically extended
   by the platform.&nbsp; In contrast, context menu extension is supported in collaboration
   between the editor and the platform.&nbsp; To achieve this collaboration, an
   editor must register each context menu it contains with the platform.&nbsp;
   It should also define a command filter for each object type in the editor.&nbsp;
   A command filter makes it easier for one plug-in to add a command to objects
   in an editor defined by another plug-in.&nbsp; The target is described using
   object type and attributes.&nbsp;&nbsp; For more information on the implementation
   of this concept, refer to <a href="http://www.eclipse.org/articles/viewArticle/ViewArticle2.html" target="_top">Creating
   an Eclipse View.</a>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.14</font></b>
 <blockquote><font color="#09448D">Register all context menus in the editor
 with the platform.</font></blockquote>
 <img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.15</font></b>
 <blockquote><font color="#09448D">Implement a Command Filter for each object
 type in the editor.</font></blockquote>
 <hr>
 <p>

 <h4>
 Resource Deletion</h4>
 When a resource is deleted from one of the navigators (e.g., Navigator
 view, J2EE view, Data view, or DBA Explorer view in IBM's WebSphere Studio), the handling of any
 editor that is currently open on that resource depends on whether the editor has any unsaved changes.
 <p>If the editor does not contain any changes since the resource was last
 saved then the editor should be immediately closed.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.16</font></b>
 <blockquote><font color="#09448D">If the input to an editor is deleted,
 and the editor contains no changes, the editor should be closed.</font></blockquote>
 <hr>
 <p>
 If the editor contains changes to the resource since the resource was last
 saved (i.e., it is "dirty"), the editor should give the user a chance to
 save their changes to another location, and then close.&nbsp; Here is a
 sample of the dialog which should be displayed:
 <p><img src="images/fileDeletedDialog.gif" hspace="40" height=124 width=436>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.17</font></b>
 <blockquote><font color="#09448D">If the input to an editor is deleted,
 and the editor contains changes, the editor should give the user a chance
 to save their changes to another location, and then close.</font></blockquote>
 <hr>
 <p>

 <h4>
 Unsaved Changes</h4>
 If the editor contains changes to the resource since the resource was last
 saved (i.e., it is "dirty"), an asterisk should be used to prefix the resource
 name presented in the editor tab:
 <p><img src="images/dirtyEditor.gif" hspace="40" height=331 width=334>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.18</font></b>
 <blockquote><font color="#09448D">If the resource is dirty, prefix the resource
 name presented in the editor tab with an asterisk.</font></blockquote>
 <hr>
 <p>


 <h4>
 Read Only Files</h4>
 With a name like "editor", it's not surprising that the issue of read-only
 files may cause confusion.&nbsp; If it's read-only, how can you edit it?&nbsp;
 In this case, you should fall back to first principles.
 <blockquote>A view is typically used to navigate a hierarchy of information,
 open an editor, or display properties for the active editor.&nbsp; An editor
 is typically used to edit or browse a file, document or other input object.</blockquote>
 This statement is appropriate whether a file is read-only or not.&nbsp;
 In either case, the user should be able to select the file, open it, and
 browse the contents within an editor. If the file is read-only, the File
 > Save command should be disabled and the File > Save As should be enabled.
 In the status bar area, "Read-only" should be shown instead of the default
 "Writable" message.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.19</font></b>
 <blockquote><font color="#09448D">Treat read-only editor input as you would
 any other input.&nbsp; Enable the Save As if possible. Display "Read-only"
 in the status bar area.</font></blockquote>
 <hr>
 <p>

 <h4>
 Integration with Other Views</h4>
 In Eclipse, there is a special relationship between each editor and the
 Outline view.&nbsp; When an editor is opened, the Outline view will connect
 to the editor, and ask it for an outline model.&nbsp; If the editor answers
 an outline model, that model will be displayed in the Outline view whenever
 the editor is active.&nbsp; The outline is used to navigate through the content, or interact with the edit data at a higher level of abstraction.
 <p>For instance, if you open a .java file in an editor, the structure of
 the class is displayed in the Outline view.&nbsp; If you select a method
 or field in the outline, the text declaration of that item will be selected
 and revealed in the editor.&nbsp;&nbsp; If you select a method or field,
 and open the context menu, you can interact with the item as a conceptual
 unit, rather than just a bunch of text.
 <p>In general, an editor should provide an outline model to the Outline
 view if the data within the editor is too extensive to see on a single
 screen, and will yield a structured outline.&nbsp; This structured outline
 makes it very easy to navigate through objects like a java file or html
 file.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.20</font></b>
 <blockquote><font color="#09448D">If the data within an editor is too extensive
 to see on a single screen, and will yield a structured outline, the editor
 should provide an outline model to the Outline view.</font></blockquote>
 <hr>
 <p>

 <p><br>When an editor has an interaction with the Outline view, notification
 about location should be two-way. That is, the user should be able to select
 something in the outline and have the editor position updated, and the
 user should be able to select something in the editor pane and have the
 outline view updated.
 <p>A context&nbsp; menu should be available, as appropriate, in the outline
 view which should support creation operations as appropriate.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.21</font></b>
 <blockquote><font color="#09448D">Notification about location between an
 editor and the Outline view should be two-way. A context menu should be available
 in the Outline view as appropriate.</font></blockquote>
 <hr>
 <p>

 <p><br>If the edit model contains errors or warnings, they should be indicated
 in the Outline view.&nbsp; An error or warning image should be added to
 the item with the error or warning respectively.&nbsp; A container should have a red X if it there are errors on the container itself, a gray X if any of its descendents have errors (but not the container itself), and no X if neither the container nor any of its descendents have errors. For instance, in the
 following line, the addFastView method has an error, so an error image
 is added to the item and its parent.
 <br>&nbsp;
 <p><img src="images/errorsInOutline.gif" hspace="40" height=284 width=223>
 <br>&nbsp;
 <p>For this to work, care must be taken to design icons with overlay in
 mind, so that glyphs can be applied to the ancestor's icon.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.22</font></b>
 <blockquote><font color="#09448D">An error or warning image should be added
 to items with the error or warning respectively. A container should have a red X if it there are errors on the container itself, a gray X if any of its descendents have errors (but not the container itself), and no X if neither the container nor any of its descendents have errors.</font></blockquote>
 <hr>
 <p>
 In an editor, task objects are commonly used to mark a location within
 a document.&nbsp; Once a task has been created, it appears in the Task
 view.&nbsp; If the task is selected, you may reopen the editor at the location
 defined in the Task.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.23</font></b>
 <blockquote><font color="#09448D">If appropriate, implement the "Add Task"
 feature in your editor.</font></blockquote>
 <hr>
 <p>
 A bookmark object can also be used mark a location within a document.&nbsp;
 Once a bookmark has been created, it appears in the Bookmarks view.&nbsp;
 If the bookmark is selected, you may reopen the editor at the location
 defined in the Task.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.24</font></b>
 <blockquote><font color="#09448D">If appropriate, implement the "Add Bookmark"
 feature in your editor.</font></blockquote>
 <hr>
 <p>

 <h4>
 Line Numbers</h4>
 Editors with source lines of text should have line numbers, and optionally
 column numbers.&nbsp; Editors should also support Navigate -> Goto Line...
 menu allowing users to quickly jump to a desired
 line.&nbsp; The current line and column numbers should be shown in the status line (column number is optional).  It's optional for the editor to show line numbers for each line in the editor itself.
 <BR>
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.25</font></b>
 <blockquote><font color="#09448D">Editors with source lines of text should show the current line and optionally column numbers  the status line. It's optional for the editor to show line numbers for each line in the editor itself.</font></blockquote>
 <hr>
 <p>

 <h4>
 Table Cell Editors</h4>
 <P>If the editor contains tables with editable cells, a single-click over a cell should select the current item and put the cell
 into edit mode. In edit mode, any dropdowns, buttons, or other controls
 in the cell should be rendered upon the single-click.</P><p><img src="images/cellTableEditor.gif" hspace="40" height=383 width=284>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.26</font></b>
 <blockquote><font color="#09448D">Table cell editors should support the
 single-click activation model, and in edit mode, they should render complex
 controls upon single-click.</font></blockquote>
 <hr>
 <p>

 <p><br>In addition, changes should be committed once a user clicks off
 the cell or hits ENTER.
 <p>The following are examples of good behaviour for a table cell editor:
 <p>- when put in edit mode, drop-down appears with current selection active
 &amp; highlighted
 <br><img src="images/cell1.gif" hspace="40" height=17 width=114>
 <p>- when cursoring through drop-down using arrow keys, it is possible
 to move up and down any number of choices and the drop-down stays visible
 until user makes an explicit selection
 <br><img src="images/cell2.gif" hspace="40" height=97 width=56>
 <p>- first letter navigation is supported as a cursoring technique when
 the drop-down is visible
 <br>- supports the "Enter" key as a way of making an explicit selection
 via the keyboard when the drop-down is visible
 <br>- supports the "Esc" key as a way of canceling a selection via the
 keyboard when the drop-down is visible
 <br>- when put in edit mode, the drop-down control (the down-arrow image) appears with current selection active
 &amp; highlighted
 <br><img src="images/cell3.gif" hspace="40" height=17 width=114>
 <p>- when put in edit mode, it is possible to arrow key through the choices
 to make a selection without needing to invoke the drop-down
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.27</font></b>
 <blockquote><font color="#09448D">Changes made in a table cell editor should
 be committed when a user clicks off the cell or hits the "Enter" key. Selection
 should be cancelled when user hits the "Esc" key.First letter navigation
 should be supported as a cursoring mechanism within a cell.</font></blockquote>
 <hr>
 <p>

 <h4>
 Error Notification</h4>
 If you are doing keystroke by keystroke validation in an editor, use red squiggles to underline the invalid content. When users move the mouse over the red squiggles, display the error text in a fly-over pop up box.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.28</font></b>
 <blockquote><font color="#09448D">When performing fine-grain error validation
 in an editor, use red squiggles to underline the invalid content. When users move the mouse over the red squiggles, display the error text in a fly-over pop up box.</font></blockquote>
 <hr>
 <p>
 When the Save command is invoked in an editor, use the Task view for showing
 errors which are persisted.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.29</font></b>
 <blockquote><font color="#09448D">Use the Task view to show errors found
 when the Save command is invoked.</font></blockquote>
 <hr>
 <p>

 <h4>
 Interaction With External Editors</h4>
 While a resource is opened within the workbench, if modifications are made
 to it outside of the workbench, we recommend the following approach to
 handle this situation. When the Save command is invoked in the editor, users
 should be prompted to either override the changes made outside of the workbench,
 or back out of the Save operation.
 If desired, this user prompt can be invoked sooner such as when the editor regains the focus.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 6.30</font></b>
 <blockquote><font color="#09448D">If modifications to a resource are made
 outside of the workbench, users should be prompted to either override the
 changes made outside of the workbench, or back out of the Save operation
 when the Save command is invoked in the editor.</font></blockquote>


 <h3>
 <a NAME="Views"></a>Views</h3>
 A view is a visual component within a workbench page.&nbsp; It is<font color="#000000">
 used in a support role for the primary task.&nbsp; You use them to navigate
 a hierarchy of information, open an editor, or view properties for the
 active editor.</font>
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.1</font></b>
 <blockquote><font color="#09448D">Use a view to navigate a hierarchy of
 information, open an editor, or display the properties of an object.</font></blockquote>
 <hr>
 <p>
 Modifications made in a view should be saved immediately.&nbsp; For instance,
 if a file is modified in the Navigator, the changes are committed to the
 workspace immediately.&nbsp; A change made in the Outline view is committed
 to the edit model of the active editor immediately.&nbsp; For changes made
 in the Properties view, if the property is a property of an open edit model,
 it should be persisted to the edit model. If it is a property of a file,
 persist to file.
 <p>In the past, some views have tried to implement an editor style lifecycle,
 with a Save command.&nbsp; This can cause confusion.&nbsp; The File menu
 within a workbench window contains a Save command, but it only applies to
 the active editor.&nbsp; It should not target the active view.&nbsp; This
 leads to a situation where the File > Save command is in contradiction to
 the Save command within the view.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.2</font></b>
 <blockquote><font color="#09448D">Modifications made within a view must
 be saved immediately.</font></blockquote>
 <hr>
 <p>
 Within a perspective, only one instance of a particular view can be opened.&nbsp;
 This policy is designed to simplify part management for a user.&nbsp; The
 user opens a view by invoking Perspective > Show View.&nbsp; If, for any
 reason, they lose a view, or forget about its existence, they can simply
 invoke Perspective > Show view again to make the view visible.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.3</font></b>
 <blockquote><font color="#09448D">Only one instance of a view may exist
 in a perspective.</font></blockquote>
 <hr>
 <p>
 In a multi-tasking world, humans often perform more than one task at a
 time.&nbsp; In Eclipse, task separation can be achieved by creating a separate
 perspective for each task.&nbsp; In reflection of this, a view must be able to be opened in more than one perspective.&nbsp; If only one
 instance of a view may exist, the ability to multi-task is taken away.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.4</font></b>
 <blockquote><font color="#09448D">A view must be able to be opened in more than one perspective.</font></blockquote>
 <hr>
 <p>
 A view can be opened in two ways: by invoking Window > Show View >
 X menu, where X is the name of the view, or by invoking another command
 within the workbench.&nbsp; For instance, if you select a class in the
 Packages view, and invoke Open Type Hierarchy, a Hierarchy view opens with
 the class hierarchy for the selection.
 <p>It should be possible to open any view from the Window > Show View
 menu, either as an explicit item within the menu, or as an item within
 the Window > Show View > Other... dialog.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.5</font></b>
 <blockquote><font color="#09448D">A view can be opened from the Window
 > Show View menu.</font></blockquote>
 <hr>
 <p>

 <h4>
 Appearance</h4>
 A view consists of a title area, a toolbar, a pulldown menu, and an embedded
 control.
 <p>The view label in the title bar must be prefixed with label of the view
 in Perspective > Show View menu.&nbsp; Given that it is impossible to change
 the entry in the Show View menu, this means you cannot change the name
 of a view.&nbsp; However, you can add additional text to the view label,
 to clarify the state of the view.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.6</font></b>
 <blockquote><font color="#09448D">The view label in the title bar must
 be prefixed with the label of the view in the Perspective > Show View menu.</font></blockquote>
 <hr>
 <p>
 In most cases, a view will contain a single control or viewer.&nbsp; However,
 it is possible to embed more than one viewer or control in the view.&nbsp;
 If these controls are linked, such that selection in one control changes
 the input of another, it may be better to separate the view into two. Users
 will have greater freedom to open one of the results views, as their needs
 arise. Special relationships can also be set up between these views to
 support the user task. In addition, this makes it easier for users to create
 a new perspective with a diverse set of views.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.7</font></b>
 <blockquote><font color="#09448D">If a view contains more than one control,
 it may be advisable to split it up into two or more views.</font></blockquote>
 <hr>
 <p>

 <h4>
 Initialization</h4>
 When a view is opened, the input of the view should be derived from the
 state of the perspective.&nbsp; The view may consult the window input
 or selection, or the state of another view.&nbsp; For instance, if the
 Outline view is opened, it will determine the active editor, query the
 editor for an outline model, and display the outline model.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.8</font></b>
 <blockquote><font color="#09448D">When a view first opens, derive the view
 input from the state of the perspective.</font></blockquote>
 <hr>
 <p>
 If the view is used to navigate a hierarchy of resources (i.e., the Navigator
 or Packages view), the input of the view may be derived from the window
 input.&nbsp; The window input defines the scope of visible resources
 within the perspective, and is defined by the user if they select a resource
 in the Navigator and invoke Open in New Window.&nbsp; For instance, if the
 Navigator view is opened, it will ask its perspective for the window
 input.&nbsp; The result is used as the initial input for the view.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.9</font></b>
 <blockquote><font color="#09448D">If a view displays a resource tree, consider
 using the window input as the root of visible information in the view.</font></blockquote>
 <hr>
 <p>

 <h4>
 Menus</h4>
 <P>Use the view pulldown menu for presentation commands, not
 selection-oriented commands.&nbsp;
 These are commands which affect the presentation of the view, but not the
 objects within the view.&nbsp;Do not put presentation commands in the context menu. For instance, the Sort and Filter commands
 within the Navigator view affect the presentation of resources, but do
 not affect the resources themselves.
 </P><p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.10</font></b>
 <blockquote><font color="#09448D">Use the view pulldown menu for presentation commands, not
 selection-oriented commands.</font></blockquote>
 <hr>
 <p>
 For consistency with other views in Eclipse, each view should adopt a common
 order for commands within the pulldown menu.&nbsp; This order is shown
 in the following table.
 <br>&nbsp;
 <table class="indent" border="1" cellspacing="0" cellpadding="3" cols="1" width="654">
 <tr>
 <td width="415">View modes (e.g. the 3 modes in the Hierarchy view)</td>
 </tr>

 	<TR>
 		<TD width="415" height="38">[separator required]</TD>
 	</TR>
 	<TR>
 		<TD width="415" height="35">Working sets (e.g. Select/Deselect/Edit Working Set, used in Navigator and Package Explorer)</TD>
 	</TR>
 	<TR>
 		<TD width="415" height="33">[separator required]</TD>
 	</TR>
 	<TR>
 		<TD width="415">Sorting</TD>
 	</TR>
 	<TR>
 		<TD width="415">[optional separator]</TD>
 	</TR>
 	<TR>
 		<TD width="415">Filtering</TD>
 	</TR>
 	<TR>
 		<TD width="415">[optional separator]</TD>
 	</TR>
 	<TR>
 		<TD width="415">View layout (e.g. Horizontal vs. Vertical in Hierarchy view)</TD>
 	</TR>
 	<tr>
 <td width="415">[optional separator]</td>
 </tr>

 	<TR>
 		<TD width="415">Link with Editor</TD>
 	</TR>
 	<TR>
 		<TD width="415">[separator required]</TD>
 	</TR>
 	<tr>
 <td width="415">Other presentation commands from the view itself</td>
 </tr>

 	<TR>
 		<TD width="415">[separator required]</TD>
 	</TR>
 	<TR>
 		<TD width="415">Presentation commands from other plug-ins</TD>
 	</TR>
 </table>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.11</font></b>
 <blockquote><font color="#09448D">Use the standard order of commands for view pulldown
 menus.</font></blockquote>
 <hr>
 <p>

 <h4>
 Toolbars</h4>
 The toolbar is used to expose the most commonly used commands in a view.&nbsp;
 Any command which appears in the toolbar must also appear in the menu (either the context menu or the view menu), but
 there is no need to duplicate every command in the menu within the toolbar.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.12</font></b>
 <blockquote><font color="#09448D">Put only the most commonly used commands on the toolbar.  Any command on a toolbar must also appear in a menu, either the context menu or the view menu.</font></blockquote>
 <hr>
 <p>

 <h4>
 Context Menus</h4>
 A context menu should be used for context sensitive interaction with the
 objects in a view.&nbsp; If an object is selected in a view, and the context
 menu is opened, the context menu should only contain actions which are
 appropriate for the selection.&nbsp; Actions which affect the presentation
 of the view should not appear in the context menu.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.13</font></b>
 <blockquote><font color="#09448D">Fill the context menu with selection
 oriented actions, not presentation actions.</font></blockquote>
 <hr>
 <p>
 For consistency with other views in Eclipse, each view should adopt a common
 order for commands within the context menu.&nbsp; This order is shown in
 the following table.&nbsp; Within this table, each item represents a category
 of commands.&nbsp; The categories within the context menu should be kept
 distinct from one another through the use of separators.
 <br>&nbsp;

 <table class="indent" border="1" cellspacing="0" cellpadding="3" width="477" cols="1">
 <tr>
 <td>New</td>
 </tr>

 <tr>
 <td>Open</td>
 </tr>

 <tr>
 <td>Navigate + Show In</td>
 </tr>

 <tr>
 <td>Cut, Copy, Paste, Delete, Move, Rename and other refactoring commands</td>
 </tr>

 <tr>
 <td>Other Plugin Additions</td>
 </tr>

 <tr>
 <td>Properties</td>
 </tr>
 </table>

 <p>The New category contains actions which create new objects.&nbsp; The
 Open category contains actions which open the selection in an editor.&nbsp;
 Navigate contains actions to refocus the view input, or reveal the view
 selection in another view.&nbsp; And the other categories are self explanatory.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.14</font></b>
 <blockquote><font color="#09448D">Use the standard  order of commands for view context
 menus.</font></blockquote>
 <hr>
 <p>
 For good spatial navigation of the menu, fill the context menu with a fixed set of
 commands for each selection type.&nbsp; Once the contents have been defined,
 the enablement state of each command should be determined using the selected
 object state.&nbsp; In doing so, you establish a consistency which makes
 the menu more predictable, and easier to navigate.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.15</font></b>
 <blockquote><font color="#09448D">Fill the context menu with a fixed set
 of commands for each selection type, and then enable or disable each to
 reflect the selection state.</font></blockquote>
 <hr>
 <p>
 An object in one view may be visible in many other views or editors.&nbsp;
 For instance, a .java file is visible in the Navigator, the Hierarchy view,
 and the Packages view.&nbsp; To the user, these objects are all the same,
 regardless of location, so the context menu for the .java file should be
 the same in each.
 <p>Implementation tip:<BR>
 To achieve a consistent context menu, plug-in developers which introduce
 a new object type should contribute commands to the context menu using an
 action group(ActionGroup class), a Java class which populates the context menu.&nbsp; If
 this approach is used, the  action group can be reused by other views where the
 same objects appear.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.16</font></b>
 <blockquote><font color="#09448D">If an object appears in more than one
 view, it should have the same context menu in each.</font></blockquote>
 <hr>
 <p>
 One of the primary goals for the platform UI is extensibility.&nbsp; In
 fact, it is this extensibility which gives you the freedom to add new views,
 editors, perspectives, and actions to the platform.&nbsp; Of course, extensibility
 is a two way street.&nbsp; While you may wish to extend the platform, others
 may wish to extend your view or editor.&nbsp; It is common for one plug-in
 to add actions to the menu, toolbar, or context menu of a view from another
 plugin.
 <p>In the platform, the menu and toolbar for a view are automatically extended
   by the platform.&nbsp; In contrast, context menu extension is supported in collaboration
   between the view and the platform.&nbsp; To achieve this collaboration, a view
   must register each context menu it contains with the platform.&nbsp; It should
   also define a command filter for each object type in the view.&nbsp; A command
   filter makes it easier for one plug-in to add a command to objects in a view
   defined by another plug-in.&nbsp; The command target is described using object
   type and attributes.&nbsp;&nbsp; For more information on the implementation
   of this concept, refer to <a href="http://www.eclipse.org/articles/viewArticle/ViewArticle2.html" target="_top">Creating
   an Eclipse View.</a>
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.17</font></b>
 <blockquote><font color="#09448D">Register all context menus in the view
 with the platform.</font></blockquote>
 <img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.18</font></b>
 <blockquote><font color="#09448D">Implement a Command Filter for each object
 type in the view.</font></blockquote>
 <hr>
 <p>

 <h4>
 Integration with the Window Menu Bar and Toolbar</h4>
 The window menu bar contains a number of global commands, such as Cut, Copy,
 and Paste within the Edit menu.&nbsp; These commands target the active part,
 as indicated by a shaded title area.&nbsp; If these commands are supported
 within a view, the view should hook these window commands, so that selection
 in the window menu bar or toolbar produces the same result as selection
 of the same command in the view.
 <p>A complete list of the global commands and built-in menus as declared in IWorkbenchActionConstants.java
 (see below).
 <p><tt></tt>File menu: Revert, Move, Rename, Refresh, Print, Properties<BR>
 Edit menu: Undo, Redo, Cut, Copy, Paste, Delete, Select All, Find/Replace, Add Bookmark, Add Task<BR>
 Navigate menu: Go Into, Back, Forward, Up One Level, Next, Previous, Back, Forward<BR>
 Project menu: Open Project, Close Project, Build Project, Rebuild Project
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.19</font></b>
 <blockquote><font color="#09448D">If a view has support for Cut, Copy,
 Paste, or any of the global commands, these commands must be executable from
 the same commands in the window menu bar and toolbar.</font></blockquote>
 <hr>
 <p>
 <font color="#000000">Although a view can't directly contribute to the main menubar or toolbar in Eclipse v2.1, it can still cause commands to appear there using &quot;action set / part associations&quot; (the actionSetPartAssociations extension point) which lets you associate action sets with particular parts (views or editors).  For example, the Java tooling in Eclipse  uses this for the Package Explorer.<BR>
 <BR>
 All commands for the view (or editor) should be made available on the main menubar, and only frequently used commands are on the context menu.<BR>
 <BR>
 In addition, the primary perspective(s) for such views (e.g. the Java and Java Browsing perspectives) should already have these action sets associated with the perspective, to improve UI stability.<BR>
 <BR></font></P>
 <h4>
 Persistence</h4>
 One of the primary goals for the platform UI is to provide efficient interaction
 with the workspace.&nbsp; In the platform this is promoted by saving the
 state of the workbench when a session ends (the workbench is shut down).&nbsp;
 When a new session is started (the workbench is opened), this state is
 restored, reducing the time required for the user to get back to work.
 <p>If a view has a static input object, in the sense that its input is not derived
   from selection in other parts, the state of the view should be persisted between
   sessions. If a view has a dynamic or transient input object, there is no need
   to persist its state between sessions. Within the workbench, the state of the
   Navigator view, including the input and expansion state, is saved between sessions.
   For more information on the implementation of persistence, see "<a href="http://www.eclipse.org/articles/viewArticle/ViewArticle2.html" target="_top">Creating
   an Eclipse View</a>". <br>
   &nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 7.20</font></b>
 <blockquote><font color="#09448D">Persist the state of each view between
 sessions.</font></blockquote>

 <p><BR></P>

 <HR>
 <P><FONT color="#000000">Navigation views should support &quot;Link with
 Editor&quot; on the view menu. In Eclipse v2.1, this feature works on a
 per-view setting. If it's expected that users will toggle it frequently,
 then it can also go on the toolbar, but this is not required (the
 Hierarchy view and the views in the Java Browsing perspective support
 it, but don't have it on the toolbar, since they expect linking to
 almost always be on).<BR>
 <BR>
 The behaviour of &quot;Link with Editor&quot; is:</FONT></P>
 <UL>
 	<LI>when toggled off, no linking occurs (either view-&gt;editor or
 	editor-&gt;view)</LI>
 	<LI>when toggled on, linking occurs in both directions:
 	<UL>
 		<LI>view-&gt;editor: when the selection is changed in the view, it
 		brings any corresponding previously-open editor to front, but does not
 		activate it (the view must keep focus)</LI>
 		<LI>editor-&gt;view: when the user switches between editors, the view
 		updates its selection to correspond to the active editor</LI>
 	</UL>
 	</LI>
 	<LI>when turned on, it should immediately synchronize the selection in
 	the view with the frontmost editor, if applicable</LI>
 	<LI>this is not the same as single-click mode -- it does not cause new
 	editors to be opened</LI>
 	<LI>changing the setting affects only the current view instance, not
 	other instances of the same type</LI>
 	<LI>the view should persist the state of this setting separately for
 	each view instance, and also globally (but separately for each view
 	type, e.g. Navigator and Package Explorer persist their last setting
 	separately)</LI>
 	<LI>when opening a new instance of the view, it should use the last
 	global setting</LI>
 	<LI>the default setting (if there's no previously persisted global
 	setting) is up to the view, but primary navigation views like the
 	Navigator and Package Explorer default to off</LI>
 </UL>
 <P><IMG src="images/guidelineIndicator.gif" height="16" width="16"><B><FONT
 	color="#09448D">Guideline 7.21</FONT></B></P>
 <BLOCKQUOTE><FONT color="#09448D"><FONT
 	color="#000000"></FONT>Navigation views should
 support &quot;Link with Editor&quot; on the view menu<FONT color="#000000"></FONT></FONT></BLOCKQUOTE>

 <P><BR>

 </P>
 <h3>
 <a NAME="Perspectives"></a>Perspectives</h3>
 A perspective is a visual container for a set of views and editors (parts).&nbsp;
 Different perspectives can have different sets of views open, but if they both have the same view open, it's shared between them (but only if they are in the same workbench window).  Editors are always all shared between perspectives in the same window.
 <p>A new perspective is opened by invoking Window -> Open Perspective -> X, where
 X identifies a particular perspective in Eclipse.&nbsp; The result is a
 new perspective in the workbench window with <i>type</i> X.&nbsp; For instance,
 if you invoke Window -> Open Perspective -> Resource, a new perspective is opened
 with type <i>Resource</i>.&nbsp; Eclipse comes with a pre-defined number
 of perspective types, such as Resource, Java, and Debug.&nbsp; The perspective
 type determines the initial layout of views, and visibility of command sets
 within the perspective.
 <p>As a plug-in developer, you may contribute new perspective types to Eclipse.&nbsp;
   To do this, you must define a perspective extension.&nbsp; Each extension has
   a <i>perspective factory</i>, a Java class which defines the initial layout
   of views, and visibility of command sets within the perspective.&nbsp; You can
   also add your own actions or views to an existing perspective type.&nbsp; For
   more information on the implementation of these concepts, see <a href="http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html" target="_top">Using
   Perspectives in the Eclipse UI</a>.
 <p>A new perspective type should be created when there is a group of related
 non-modal tasks which would benefit from a predefined configuration of commands and
 views, and these tasks are long lived.&nbsp; A task oriented approach is
 imperative.&nbsp; As a development environment, Eclipse was designed to
 fulfill the needs of a large product development team, from product manager
 to content developer to product tester.&nbsp; It is fully extensible and
 may be configured with hundreds of command, wizard, view and editor extensions.&nbsp;
 In other words, it may contain a lot of features you'll never use.&nbsp; To
 avoid the visual overload and confusion which would occur if everything
 was visible in the UI, a perspective can be used to limit the presentation to a task-oriented set of views and command sets.
 <p>For instance, the task of Java code creation is long lived and complex,
 so the creation of a Java perspective is warranted.&nbsp; In Eclipse, the
 Java perspective contains an editor area, Packages Explorer view, Hierarchy view,
 Tasks view, and Outline view.&nbsp; The Java and Debug command sets are
 also visible.&nbsp; Together, these components are useful for a variety
 of long lived, Java coding tasks.
 <p>It is not appropriate to create a new perspective type for short lived
 tasks.&nbsp; For instance, the task of resource check-in is short lived,
 so it may be better performed using a view in the current perspective.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.1</font></b>
 <blockquote><font color="#09448D">Create a new perspective type for long
 lived tasks, which involve the performance of smaller, non-modal tasks.</font></blockquote>
 <hr>
 <p>
 If your plug-in contributes a small number of views, and these augment
 an existing task, it is better to add those views to an existing perspective.&nbsp;
 For instance, if you create a view which augments the task of Java code
 creation, don't create a new perspective.&nbsp; Instead, add it to the
 existing Java perspective.&nbsp; This strategy provides better integration
 with the existing platform.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.2</font></b>
 <blockquote><font color="#09448D">If you just want to expose a single view,
 or two, extend an existing perspective type.</font></blockquote>
 <hr>
 <p>

 <h4>
 View Layout</h4>
 If the user opens a new perspective, the initial layout of views will be
 defined by the perspective type (i.e., Resource, Java).&nbsp; This
 layout is performed in the <i>perspective factory</i>, a Java class associated
 with the perspective type.&nbsp; When the perspective is initialized, it
 consists of an editor area with no additional views.&nbsp; The perspective
 factory may add new views, using the editor area as the initial point of
 reference.
 <p>The size and position of each view is controlled by the perspective
 factory.&nbsp;&nbsp; These attributes should be defined in a reasonable
 manner, such that the user can resize or move a view if they desire it.
 An important issue to consider is the overall flow between the views (and editors) in the perspective.  For example,  initially the navigation views may be placed to the left of the editor area, outline views may be placed either to the right of the editor area or below the navigation view, and other supporting views may be placed below and to the right of the editor area.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.3</font></b>
 <blockquote><font color="#09448D">The size and position of each view in
 a perspective should be defined in a reasonable manner, such that the user
 can resize or move a view if they desire it. When defining the initial layout, it is important to consider the overall flow between the views (and editors) in the perspective.</font></blockquote>
 <hr>
 <p>
 A perspective should have at least two parts, including the visible views
 and the editor area.&nbsp; If this is not the case, then the perspective
 should be re-examined to determine if it is better suited as a view or
 editor.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.4&nbsp;</font></b>
 <blockquote><font color="#09448D">If a perspective has just one part, it
 may be better suited as a view or editor.</font></blockquote>
 <hr>
 <p>
 In some scenarios, it may be undesirable to have an editor area within
 a perspective.&nbsp; In this case, the perspective factory should hide
 the editor area, using the existing java methods.&nbsp; It is not acceptable
 to resize the editor area to a point where it is no longer visible.&nbsp;
 If the user does open an editor in the perspective, for whatever reason,
 they will be unable to see or resize it.
 <p>When the editor area is programmatically hidden, if the user opens an
 editor in the perspective, the editor area will become visible. The view
 that occupied the editor area before will be shrunk. Therefore, it is
 important to define a non-empty editor area even when the editor is programmatically
 hidden.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.5</font></b>
 <blockquote><font color="#09448D">If it is undesirable to have an editor
 area in a perspective, hide it.&nbsp; Do not resize the editor area to
 the point where it is no longer visible.</font></blockquote>
 <hr>
 <p>

 <h4>
 Command Contribution</h4>
 The perspective factory may add actions to the File > New, Window > Open Perspective
 , and&nbsp; Window > Show View menus.&nbsp; It is also possible
 to add one or more command sets to the window.&nbsp; In each case, you should
 choose commands which are relevant to the task orientation of the perspective.
 <p>The File > New menu should be populated with wizards for the creation
 of objects commonly used in the task.&nbsp; For instance, in the Java perspective
 the File > New menu contains menu items for the creation of packages, classes,
 and interfaces.
 <p>The Window > Show View menu should be populated with the initial
 views in the perspective, as well as any extra views that may be important
 for the task at hand.
 The Navigate &gt; Show In menu should be used to allow users to navigate in their contents.<p><img src="images/showViewMenu.gif" hspace="40" height=325 width=486>
 <br>&nbsp;
 <p>The application development lifecycle should be considered when populating
 the the Window - Open Perspective menu.&nbsp; The development of most applications
 follow a well defined lifecycle, from designing / modeling, to editing
 / creating, to debugging / testing, to assembling / deploying.&nbsp; Each
 perspective will fall into one of these steps.&nbsp; The Open
 Perspective menu should be used to link the current perspective to perspectives
 that support tasks immediately downstream of the current one, as well as
 tasks further upstream, to allow for iterative development.
 <p>For instance, the Java perspective is used in a larger lifecycle, involving
 Java and Debug tasks.&nbsp; The Window > Open Perspective menu is populated
 with each of these perspectives.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.6</font></b>
 <blockquote><font color="#09448D">Populate the window menu bar with commands
 and command sets which are appropriate to the task orientation of the perspective,
 and any larger workflow.</font></blockquote>
 <hr>
 <p>

 <h4>
 Opening a Perspective in Code</h4>
 A command should only open a new perspective if the user explicitly states
 a desire to do so.&nbsp; If the user does not state a desire to do so,
 it may cause loss of context.
 <p>For instance, imagine a scenario where the user selects an object and
 invokes a command.&nbsp; In the perspective where the command is invoked,
 the user may have a set of views and editors open.&nbsp; These represent
 the working state, or context, of the user.&nbsp; If a new perspective
 is created, that context will be left behind, forcing the user to recreate
 the context.&nbsp; This is time wasted.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.7 </font></b>
 <blockquote><font color="#09448D">A new perspective should be opened only
 if the user explicitly states a desire to do so.&nbsp; In making this statement,
 the user agrees to leave their old context, and create a new one.</font></blockquote>
 <hr>
 <p>
 In some cases, a new perspective is opened as the side effect of another
 command.&nbsp; For instance, if users start debugging their application code, they may be switched to the Debug perspective.&nbsp; If this
 behavior is implemented, the user should have the option to turn this behavior
 off.&nbsp; The option can be exposed in the command dialog, or within a
 Preference page.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.8</font></b>
 <blockquote><font color="#09448D">If a new perspective is opened as a side
 effect of another command, the user should be able to turn this behavior
 off.</font></blockquote>
 <hr>
 <p>
 If a new perspective is opened, it may be opened within the current
 window, or in a new window.&nbsp; The user controls this option using the
 Workbench preferences.&nbsp; If code within a plug-in opens a new perspective,
 the plug-in should honor the user preference.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.9</font></b>
 <blockquote><font color="#09448D">If a new perspective is opened, it should
 be opened within the current window, or in a new window, depending
 on the user preference.</font></blockquote>
 <hr>
 <p>
 With regard to command contributions applied to the New, Open Perspective,
 and Show View menus, the list of wizards, perspectives, and views added
 as shortcuts to these menus should be at most 7 plus / minus 2 items.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 8.10</font></b><blockquote><font color="#09448D">The list of shortcuts added to the New,
 Open Perspective, and Show View menus should be at most 7 plus / minus
 2 items.</font></blockquote>

 <p><br>

 <h3>
 <a NAME="Windows"></a>Windows</h3>
 In this section we look at the window menu bar, toolbar, and layout.&nbsp;
 As a plug-in developer, you can contribute actions to the menu bar and
 toolbar using an <i>action set</i>, a set of task oriented actions which
 the user can show or hide.&nbsp; You can control the layout of views within
 a window by defining a <i>perspective</i>.&nbsp; In this section we'll
 look at action extension.&nbsp; For more information on perspectives, see
 <a href="#Perspectives">Perspectives</a>.
 <h4>
 Actions</h4>
 Each workbench window contains a menu bar and toolbar.&nbsp; These are
 pre-populated by the platform, but a plug-in developer may add additional
 items to each.&nbsp; This is done by defining an <i>action set</i>, a set
 of task oriented actions which the user can show or hide.&nbsp; The actions
 within an action set may be distributed throughout the window menu bar
 and toolbar.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.1</font></b>
 <blockquote><font color="#09448D">Use an Action Set to contribute actions
 to the window menu bar and toolbar.</font></blockquote>
 <hr>
 <p>
 The window menu bar contains a number of pulldown menus: File, Edit, Navigate,
 Project, Window, and Help.&nbsp; Each of these has a different purpose,
 which will be explained in the following paragraphs.&nbsp; For consistency
 with the action sets contributed by other plug-ins, the commands within
 an action set should conform to the existing distribution of actions in
 the window.&nbsp; There is no need to group the actions in a separate pulldown
 menu of the menu bar.
 <p>The File menu contains file oriented actions, such as Save, Close, Print,
 Import, Export and Exit.&nbsp; The contents of the File > New menu are
 determined by the perspective type.&nbsp; However, the user may add or
 remove items using the Window -> Customize Perspective... menu item.&nbsp; The contents
 of the Import and Export dialogs are populated with every import and export
 wizard, respectively.
 <p>The Edit menu contains editor oriented actions, such as Undo, Redo,
 Cut, Copy, and Paste.&nbsp; These actions target the active part (as indicated
 by a shaded title bar) .&nbsp; It is very common for an editor to add items
 to this menu.&nbsp; However, it is uncommon for an action set to add actions
 to the Edit Menu; action sets tend to be global in nature, while the edit
 menu targets a specific part, and interaction with the data in that part.
 <p>The Navigate menu contains navigational actions such as Go to, Open Type,
 Show In, to enable users to browse laterally or drill down in their code.
 <p>The Project menu contains actions which apply to the contents of the
 workspace, such as Rebuild All and Open Type.&nbsp; An action set may add
 actions which search the entire workspace, generate project info and so on.
 <p>The Window menu contains actions which apply to window management and
 system preferences. It also contains the Open Perspective and Show View
 submenu which contains actions affecting the state of the window contents.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.2</font></b>
 <blockquote><font color="#09448D">Follow the platform lead when distributing
 actions within an Action Set.</font></blockquote>
 <hr>
 <p>
 The toolbar contains the most commonly used actions of the menu bar.&nbsp;
 In reflection of this, you should contribute actions to the menu bar first,
 and then to the toolbar if they will be frequently used.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.3</font></b>
 <blockquote><font color="#09448D">Contribute actions to the window menu
 bar first, and then to the window toolbar if they will be frequently used.</font></blockquote>
 <hr>
 <p>
 The contents of each action set should be defined using a task oriented
 approach.&nbsp; For instance, the Java action set contains actions to create
 a new package, class and interfaces.&nbsp; It also contains a command to
 open an editor on a class, Goto Type. These form a cohesive set of related
 actions, which can be turned on and off by the user, depending on the active
 task.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.4</font></b>
 <blockquote><font color="#09448D">Define each action set with a specific
 task in mind.</font></blockquote>
 <hr>
 <p>
 The size of an action set is also important.&nbsp; If an action set is
 too large, it will flood the menu or toolbar, and reduce the users ability
 to customize the menu and toolbar.&nbsp; At the same time, if an action
 set is too small, the user may find customization of the menu and toolbar
 is too labor intensive.&nbsp; Break an action set up when it has more than
 about 7 items.
 <p>There is no magic number for the size of an action set, but it should
 be carefully designed to contain the smallest possible semantic chunking
 of actions. Avoid the temptation to provide only one action set for an
 entire plug-in.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.5</font></b>
 <blockquote><font color="#09448D">An action set should contain the smallest
 possible semantic chunking of actions. Avoid the temptation to provide
 only one action set for an entire plug-in.</font></blockquote>
 <hr>
 <p>
 An action set can be used to share a set of actions between two or more
 views and editors.&nbsp; For instance, a Java Refactor action set may be
 applicable to the selection within a Java Editor, an Outline view, and
 a Hierarchy View.&nbsp; In this situation the actions can be shared by
 defining an action set extension for the workbench.&nbsp; Once this action
 set has been defined, it can be automatically included in a perspective
 by the perspective developer, or added to a perspective by the user.
 <p>An action set should not be used to promote command from a single view
 to the window menu bar and toolbar.&nbsp; This simply clutters up the user
 interface.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.6</font></b>
 <blockquote><font color="#09448D">Use an action set to share a set of actions
 which are useful in two or more views or editors.</font></blockquote>
 <hr>
 <p>
 The set of visible command in a window may be changed by invoking Window >
 Customize Perspective.&nbsp; Within the resulting dialog, you can add or remove items
 from the File > New menu, Window > Open Perspective menu, or Window > Show
 View menu.&nbsp; It is also possible to add or remove action sets.&nbsp;
 In general, the visible action sets should be controlled by the user, and
 should never be changed programmatically.&nbsp; There are two reasons for
 this.&nbsp; First, users like to control the environment, not be controlled.&nbsp;
 And second, the user is in the best position to understand the active task,
 and the appropriate action sets for its completion.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.7</font></b>
 <blockquote><font color="#09448D">Let the user control the visible action
 sets.&nbsp; Don't try to control it for them.</font></blockquote>
 <hr>
 <p>

 A common example of a command which may be added to an action set is Navigate
 > Open Type.&nbsp; This command can be used to open an editor on a type
 which is not visible in the current window, and is a form of lateral navigation.&nbsp;
 In general, all Open actions which take the form should be added to the
 Navigate menu, for consistency.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.8</font></b>
 <blockquote><font color="#09448D">"Open Object" actions must appear in
 the Navigate pulldown menu of the window.</font></blockquote>

 <hr>
 <p>

 <h4>
 Status Bar</h4>
 If there is a need for a plug-in to show non-modal contextual information
 in the status bar area, always use the global status bar.
 For example, editors use the global status bar to show the current line and column number.<br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 9.9</font></b>
 <blockquote><font color="#09448D">Always use the global status bar to display
 status related messages.</font></blockquote>


 <h3>
 <a NAME="Properties"></a>Properties</h3>
 A Properties dialog or view is used to view / modify the properties of
 an object which are not visible in the normal presentation of that object.
 For instance, the Read Only attribute for a file is modified in the Properties
 Dialog.&nbsp; The build path for a Java Project is modified in the Properties
 Dialog.
 <p>Within Eclipse, there are two ways to edit the properties of an object:
 in the Properties dialog, and in the Properties view.&nbsp; Each of these
 is applicable in different situations.
 <p>The Properties view is commonly used to edit the properties for a set
 of objects in an editor, where quick access to the properties is important,
 and you switch from one object to another quickly.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 10.1</font></b>
 <blockquote><font color="#09448D">Use the Properties view to edit the properties
 of an object when quick access is important, and you will switch quickly
 from object to object.</font></blockquote>
 <hr>
 <p>
 The properties for an object should be quick to calculate.&nbsp; If it
 is too expensive to calculate the properties for an object, the quick access
 to properties offered by the Properties view becomes worthless.&nbsp; In
 this situation, where quick access is not possible, a Properties Dialog
 should be used.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 10.2</font></b>
 <blockquote><font color="#09448D">Use a Properties Dialog to edit the properties
 of an object which are expensive to calculate.</font></blockquote>
 <hr>
 <p>
 In some cases, the properties for an object are dependent upon one another,
 such that a change in one will affect another, or even enable / disable
 the option to change another.&nbsp; In this situation, a Properties Dialog
 may be a better way to represent the semantic link between these properties.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 10.3</font></b>
 <blockquote><font color="#09448D">&nbsp;Use a Properties Dialog to edit
 the properties of an object which contain complex relationships to one
 another.</font></blockquote>
 <hr>
 <p>
 When both the Properties view and the Properties Dialog are used to present
 and edit properties of an object, the Properties Dialog should contain
 the superset of items shown in the Properties view.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 10.4</font></b>
 <blockquote><font color="#09448D">&nbsp;Properties Dialog should contain
 the superset of items shown in the Properties view.</font></blockquote>


 <h3>
 <a NAME="Widgets"></a>Widgets</h3>
 In this section, we will describe some of the recommended designs for Standard Windows Toolkit (SWT)
 widgets.

 <p>
 <h4>Tree and Table</h4>
 For Tree and Table widgets that have a checkbox associated with a cell item,
 users can either select the item or change the checkbox state.
 Changing the current selection should not automatically change the check state
 of the selected item.
 However, the current selection should be set to a given item
 when its check state is changed (e.g. users click on the checkbox associated
 with the item).

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 11.1</font></b>
 <blockquote><font color="#09448D">For Tree and Table widgets that have a checkbox associated
 with a cell item, changing the current selection should not automatically change
 the check state of the selected item. However, the current selection should be set
 to a given item when its check state is changed.</font></blockquote><p>

 <br>
 <h2>
 <a NAME="Standard Components"></a>Standard Components</h2>
 In this section we'll look at the standard components which ship with Eclipse.&nbsp;
 The Eclipse SDK contains a number of views, including the Navigator, Outline,
 Properties, Tasks, and Bookmarks view.&nbsp; Eclipse also contains a default
 text editor and a Resource perspective.
 <p>As a plug-in developer, you should try to add new actions to the existing
 parts.&nbsp; This leads to better integration with the platform, and the
 existing knowledge of the user.
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 12.1</font></b>
 <blockquote><font color="#09448D">If appropriate, add actions to standard
 components of Eclipse using the plug-in registry.</font></blockquote>
 <hr>
 <p>

 <p><br>When extending the standard components such as the Navigator, Outline,
 Properties, Tasks, and Bookmark views, make sure your specialized components
 carry over the base component's characteristics (drag and drop support,
 keyboard navigation, selection behaviour, etc.)
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 12.2</font></b>
 <blockquote><font color="#09448D">If you subclass or copy any of the standard
 components, always carry over the standard components' characteristics.</font></blockquote>

 <p><br>


 <h3>
 <a NAME="Navigator"></a>The Navigator View</h3>
 The Navigator is used to navigate the workspace, create new resources,
 modify resources, and open an editor on a resource.&nbsp; Plug-in developers
 may contribute new actions to the menu, toolbar, and context menu.
 <br>&nbsp;
 <h4>
 Adding Actions</h4>
 This is done by adding an extension to the plug-in registry.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 13.1</font></b>
 <blockquote><font color="#09448D">Add actions to the Navigator View menu,
 toolbar, and context menu using the plug-in registry.</font></blockquote>
 <hr>
 <p>
 If object contributions are made to the context menu, try to qualify the
 target object as much as possible, to avoid adding the command to the wrong
 objects in the Navigator.&nbsp; For instance, a Java command may target
 IFiles with a .java extension, or IProjects with a Java nature.&nbsp; It
 will cause confusion if Java actions appear on non-java objects.
 <p>Some actions are a reflection of tool use, rather than object type.&nbsp;
 For instance, a repository plug-in may provide actions for file check in,
 check out, etc.&nbsp; These actions should only appear on the resources
 in the Navigator if the user has actively chosen to use the repository
 tool.&nbsp; To control the visibility of these actions, the plug-in should
 apply a project nature to the managed resources, and use the project nature
 attribute in all context menu contributions.
 <p>For more information on command filtering,&nbsp; refer to <a href="http://www.eclipse.org/articles/viewArticle/ViewArticle2.html" target="_top">Creating
   an Eclipse View</a>.&nbsp; The standard attributes for resources are defined
   in IResourceActionFilter.java (see below).
 <pre>public interface IResourceActionFilter extends IActionFilter {
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String NAME = "name";&nbsp;
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String EXTENSION = "extension";
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String PATH = "path";&nbsp;
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String READ_ONLY = "readOnly";&nbsp;
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String PROJECT_NATURE = "projectNature";&nbsp;&nbsp;
 }</pre>
 The standard attributes for project filtering are defined in IProjectActionFilter.java.
 <pre>public interface IProjectActionFilter extends IResourceActionFilter {
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String NATURE = "nature";
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String OPEN = "open";
 }</pre>
 <img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 13.2</font></b>
 <blockquote><font color="#09448D">Use the attributes defined in IResourceActionFilter.java&nbsp;
 and IProjectActionFilter.java to control the visibility of context menu
 actions in the Navigator.</font></blockquote>
 <hr>
 <p>

 <h4>
 Integration with Other Views and Editors</h4>
 In Eclipse, the use of a "Navigate -&gt; Show In" command is a common way to link the selection
 in one view to the input of another.&nbsp; For instance, a "Show in Package Explorer"
 command is visible in the context menu for a selected class in the  source editor.&nbsp;
 When invoked, the class in the source editor is selected and revealed in
 the Package Explorer view.&nbsp; This approach should be used as a general, non
 intrusive pattern for view or editor linking.&nbsp; It is context sensitive,
 and reflects the intentions of the user.
 <p>A "Navigate -&gt; Show In Navigator" command should be included in any view where a
 resource may appear.&nbsp; If invoked, the command should select and reveal
 the resource in the navigator.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 13.3</font></b>
 <blockquote><font color="#09448D">Use a "Navigate -&gt; Show In Navigator" command in each
 view, to link resources back to the Navigator.</font></blockquote>"


 <h3>
 <a NAME="Tasks"></a>The Tasks View</h3>
 The Tasks view is used to display the current tasks, errors and warnings
 in the workspace.&nbsp; A plug-in developer may contribute new tasks, errors,
 and warnings to the workspace, and rely upon the Tasks view to display
 those objects.&nbsp; You can also contribute new actions to the menu, toolbar,
 and context menu.&nbsp; This is done by adding an extension to the plug-in
 registry.
 <h4>
 Adding Tasks</h4>
 A new task, error or warning can be created using the Marker Manager services
 from the Core Resources Management plugin.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 14.1</font></b>
 <blockquote><font color="#09448D">Add markers (tasks, errors and warnings)
 to the Tasks view using the Marker Manager services from the Core Resources
 Management plugin.</font></blockquote>
 <hr>
 <p>
 The Tasks view is a table, containing columns for the task image, completion
 status, priority, description, resource, and line number.&nbsp; The description
 text of each marker should be short and concise, so that it will fit in
 the status line of Eclipse.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 14.2</font></b>
 <blockquote><font color="#09448D">The description text of each marker should
 be short and concise, so that it will fit in the status line of Eclipse.</font></blockquote>
 <hr>
 <p>

 <h4>
 Adding Actions</h4>
 You can contribute new actions to the menu, toolbar, and context menu.&nbsp;
 This is done by adding an extension to the plug-in registry.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 14.3</font></b>
 <blockquote><font color="#09448D">Add actions to the Tasks view menu, toolbar,
 and context menu using the plug-in registry.</font></blockquote>
 <hr>
 <p>
 If object contributions are made to the context menu, try to qualify the target
 object as much as possible, to avoid adding the command to the wrong objects in
 the Tasks view.&nbsp; At an implementation level, each object in the Tasks view
 is a <i>marker</i>, a general mechanism for associate notes with a resource.&nbsp;
 Use the attributes within IMarkerActionFilter.java to control the visibility of
 Task object actions (see below).&nbsp; For more information on command filtering,&nbsp;
 refer to <a href="http://www.eclipse.org/articles/viewArticle/ViewArticle2.html" target="_top">Creating
 an Eclipse View</a>.
 <pre>public interface IMarkerActionFilter extends IActionFilter {
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String TYPE = "type";
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String SUPER_TYPE = "superType";
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String PRIORITY = "priority";
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String SEVERITY = "severity";
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String DONE = "done";
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static final String MESSAGE = "message";
 }</pre>

 <p><br><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 14.4</font></b>
 <blockquote><font color="#09448D">Use the attributes defined in IMarkerActionFilter.java
 to control the visibility of context menu actions in the Tasks view.</font></blockquote>
 <hr>
 <p>

 <h4>
 Integration with Other Views and Editors</h4>
 In an editor, task objects are commonly used to mark a location within
 a document.&nbsp; Once a task has been created, it appears in the Task
 view.&nbsp; If this task is selected (via double clicking), you should
 reopen the editor at the location defined in the task. The focus should
 be changed from the Task view to the editor.
 <p>If appropriate, support for the creation of new task objects in an editor
 should be implemented by the editor.&nbsp; For more information on this,
 see <a href="#Editors">Editors</a>.
 <br>&nbsp;
 <h4>
 Adding F1 Help to Task View</h4>
 Plug-ins should support F1 keyboard command and link it to an infopop that
 gives a detailed description of the selected item in the Task view.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 14.5</font></b>
 <blockquote><font color="#09448D">Support F1 keyboard command and link it
 to an infopop that gives a detailed description of the selected item in
 the Task view.</font></blockquote>

 <p>

 <h3>
 <a NAME="The Preference Dialog"></a>The Preference Dialog</h3>
 The Preference Dialog is used to edit the global preference for a feature
 in the workbench.
 <p>A new preference page should be created when you need to expose global
 options to the user.&nbsp; For instance, the global preferences for Java
 compilation are exposed as a group of preference pages in the Preference
 Dialog.&nbsp; If these preferences are changed, they affect the entire
 Java plug-in.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 15.1</font></b>
 <blockquote><font color="#09448D">Global options should be exposed within
 the Preferences Dialog.</font></blockquote>
 <hr>
 <p>
 A preference page should not be used to expose the local options for a
 particular instance of a view, editor, or window.&nbsp;&nbsp; In this situation,
 the user will look to the menu and toolbar of the control itself to customize
 it.&nbsp; If these options are exposed in the Preference Dialog, it will
 blur the location of customization, and confuse the user.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 15.2</font></b>
 <blockquote><font color="#09448D">Expose the preferences for a particular
 view, editor or window in the view itself, via a menu or tool item.</font></blockquote>
 <hr>
 <p>

 <h4>
 Preference Page Design</h4>
 In the simplest case, any plug-in which needs to expose an option to the
 user will define a single preference page.&nbsp; This preference page should
 contain all of the options for the plug-in, until the number of options
 starts to overload the page.&nbsp; At that point a nested design for preference
 pages should be adopted.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 15.3</font></b>
 <blockquote><font color="#09448D">Start out with a single preference page.&nbsp;
 Then evolve to more if you need to.</font></blockquote>
 <hr>
 <p>
 In a nested design, a root preference page is added to the preference dialog,
 and then sub pages are added to the root preference page.&nbsp; The root
 preference page should never be blank.&nbsp; Instead, it should contain
 the most commonly used preferences, or those preferences which have a wide
 spread effect upon the plug-in behavior.&nbsp; Beneath the root page, a
 sub page should be created for each major chunk of functionality within
 the plug-in.
 <p>There is no reason to set the focus in a preference page, because focus
 is always set to the tree, by the Eclipse platform, after the preference
 page is made visible.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 15.4</font></b>
 <blockquote><font color="#09448D">If you create a preference group, use
 the root page for frequently used preferences, or those preferences which
 have wide spread effect.&nbsp; Specialize within the sub pages. The root
 preference page should not be blank.</font></blockquote>
 <hr>
 <p>

 <p><br>Each new plug-in should integrate its plug-in preferences, wizards,
 and views into existing preference, wizard, and view categories where it
 makes sense, rather than the blind creation of new categories for itself.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 15.5</font></b>
 <blockquote><font color="#09448D">Attempt to integrate plug-in preferences,
 wizards, and views into existing categories for a new plug-in first, before
 considering the creation of a new category.</font></blockquote>


 <h3>
 <a NAME="Outline"></a>The Outline View</h3>
 In Eclipse, there is a special relationship between an editor and the Outline
 view.&nbsp; When an editor is opened, the Outline view will connect to
 the editor, and ask it for an outline model.&nbsp; If the editor answers
 an outline model, that model will be displayed in the Outline view whenever
 the editor is active.&nbsp; The outline is used to navigate through the
 edit data, or interact with the edit data at a higher level of abstraction.
 <p>If you are an editor developer, the relationship between an editor and
 the Outline view is important.&nbsp; For more information on the collaboration
 between these two, see <a href="#Editors">Editors</a>.
 <p>

 <h3>
 <a NAME="The Properties View"></a>The Properties View</h3>
 The Properties view shows the properties for the active part in the workbench,
 or the selection within that part. These properties are supplied by the
 active part itself.&nbsp; The Properties view is simply a container for
 their presentation.
 <p>Within Eclipse, the properties for an object can be exposed using a
 Properties dialog, or the Properties view.&nbsp; The Properties view is
 commonly used to edit the properties for a set of objects in an editor,
 where quick access to the properties is important, and you switch from
 one object to another quickly.
 <p>For more information on the use of the Properties view, or Properties
 dialog, refer to <a href="#Properties">Properties</a>.
 <p>

 <h3>
 <a NAME="Bookmarks"></a>The Bookmarks View</h3>
 The Bookmarks view is used to bookmark files, and open them quickly.&nbsp;
 A plug-in developer may contribute new bookmarks to the workspace, and
 rely upon the Bookmarks view to display those bookmarks.&nbsp; You can
 also contribute new actions to the menu, toolbar, and context menu.&nbsp;
 This is done by adding an extension to the plug-in registry.
 <p>In an editor, bookmark objects are commonly used to mark a location
 within a document.&nbsp; Once a bookmark has been created, it appears in
 the Bookmarks view.&nbsp; If this bookmark is selected, you&nbsp; may reopen
 the editor at the location defined in the bookmark.
 <p>If appropriate, support for the creation of new bookmark objects should
 be implemented by the editor.&nbsp; For more information on this, see <a href="#Editors">Editors</a>.
 <p>

 <h3>
 <a NAME="Text Editor"></a>The Text Editor</h3>
 The Text Editor is commonly used to edit text files.&nbsp; A plug-in developer
 can contribute new actions to the menu, toolbar, and context menu.&nbsp;
 This is done by adding an extension to the plug-in registry. For more information
 on this, see <a href="#Editors">Editors</a>.
 <p>

 <h3>
 <a NAME="Resource Perspective"></a>The Resource Perspective</h3>
 The Resource perspective contains a Navigator, Outline, Task view, and
 editor area.&nbsp; Plug-in developers may contribute a new command, action
 set, or view to the Resource perspective.&nbsp; For more information, refer
 to
 <a href="#Perspectives">Perspectives</a>..
 <p>

 <br>
 <h2>
 <a NAME="Flat Look Design"></a>Flat Look Design</h2>

 The Eclipse platform provides a Web user interface, also known as Flat Look, design
 alternative for implementing content editors. For example, the editor in the
 Eclipse plug-in development environment (PDE) perspective uses Flat Look.

 <p><img src="images/flatlook1.gif" hspace="40" height=597 width=789>
 <p>

 The Flat Look design may be more suitable for certain type of user tasks,
 and more appealing to certain user profile.
 However, this design should not be used just because it provides a different look
 than the native platform look and feel. The use of Flat Look design should be
 considered in the context of the supported user scenarios. This design is usually
 a good fit for extensive property and configuration editing, such as editing
 Eclipse's plugin.xml file, and J2EE Web application's deployment descriptors.

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 16.1</font></b>
 <blockquote><font color="#09448D">Use Flat Look design for user scenarios that involve
 extensive property and configuration editing.</font></blockquote>

 <hr>
 <p>

 When required, use a "More..." button for navigation purpose (function similar to a hyperlink).


 <p><img src="images/flatlook2.gif" hspace="40" height=102 width=307>

 <p>
 On the overview page, initially expand basic or core sections, but collapse advanced sections.
 On non-overview pages, provide a "Home" icon which takes users back to the overview page


 <p><img src="images/flatlook3.gif" hspace="40" height=314 width=616>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 16.2</font></b>
 <blockquote><font color="#09448D">Have the core sections on the overview page expanded,
 and provide a "Home" icon on other pages to take users back to the overview page.</font></blockquote>

 <hr>
 <p>

 <p>
 Don't use tabs within a Flat Look editor tab. Use an alternative design or rendering
 of the tabs.


 <p><img src="images/flatlook4.gif" hspace="40" height=316 width=324>

 <p>
 When applicable, always provide a "Source" tab.
 Assign mnemonics for sections, controls, etc. for keyboard navigation.


 <p><img src="images/flatlook5.gif" hspace="40" height=344 width=406>

 <h4>
 <a NAME="Editor and Outline View Interaction"></a>Editor and Outline View Interaction</h4>

 Plug-ins that use Flat Look design for content editor should provide support for
 full two way interactions between the editor and outline view.

 <p>
 In the outline view,
 use grouping elements corresponding to tabs in the content editor for
 the organization of the tree view.


 <p><img src="images/flatlook6.gif" hspace="40" height=474 width=772>

 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 16.3</font></b>
 <blockquote><font color="#09448D">Use grouping elements corresponding to tabs
 in the Flat Look content editor for the organization of the tree view in outline view.
 </font></blockquote>
 <p>

 <br>
 <h2>
 <a NAME="The Tao of IResource"></a>The Tao of Resource</h2>
 In Eclipse, the notion of a tool disappears.&nbsp; In its place, is the
 idea of a universal tool platform - an open, extensible IDE - where tool
 plug-ins are added to extend the capabilities of the platform.&nbsp; These
 plug-ins "teach" Eclipse how to work with things - java files, web content,
 graphics, video - almost anything you can imagine.&nbsp; At an implementation
 level, these plug-ins communicate using resources (projects, folders, and
 files).&nbsp; The resource is the common medium for integration between
 plugins and external tools.
 <p>The resource concept was developed for a number of reasons:
 <br>&nbsp;
 <ol>
 <li>
 Integration between a plug-in from one vendor, and a plug-in from another,
 is only possible if there is a common, well known data abstraction.</li>

 <li>
 Integration with external tools is only possible if everything, at some
 level, is a file.</li>
 </ol>

 <p><br>Resources are also important at the UI level.&nbsp; If an object
 command, decorator, or property page contribution is made to an IResource,
 the platform will ensure that this contribution is visible in any view
 or editor where the resource appears.&nbsp; For instance, a .java file
 will be visible in the Navigator, the Hierarchy view, and the Packages
 view.&nbsp; To the user, the .java file is the same object, regardless
 of the view where it appears, so the object appearance, context menu, and
 properties should be consistent in each view.
 <p>In some cases, the implementation of a particular view or editor may
 wrap a resource within another object, for presentation purposes.&nbsp;
 If the wrapper is equivalent to a resource, it is important to expose this
 equivalence to the platform.&nbsp; If the resource is exposed, the platform
 may apply resource contributions to the resource equivalent object.&nbsp;
 This ensures presentation consistency for an object in the platform.
 <p>The underlying resource for an object is exposed by implementing IAdaptable
 on the model object, and answering an IContributorResourceAdapter.&nbsp;
 For more information on the implementation of an IContributorResourceAdapter,
 refer to Eclipse Corner.
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 17.1</font></b>
 <blockquote><font color="#09448D">Expose the resource for resource equivalent
 model objects using an IContributorResourceAdapter.</font></blockquote>

 <br>
 <h2>
 <a NAME="Accessibility"></a>Accessibility</h2>
 In a view, editor, or other control, every features should be accessible
 using a mouse or the keyboard.
 <p><font color="#000000">In a dialog or wizard, a shortcut key should be
 defined for each button or control.&nbsp; The shortcut key should be displayed
 with an underline beneath the appropriate shortcut character.</font>
 <br>&nbsp;
 <p><img src="images/guidelineIndicator.gif" height="16" width="16"><b><font color="#09448D">Guideline
 18.1</font></b>
 <blockquote><font color="#09448D">All of the features provided by a tool
 should be accessible using a mouse or the keyboard.</font></blockquote>
 <hr>
 <p>


 <h3>
 <a NAME="Standard Accelerators"></a>Standard Accelerators</h3>
 The Eclipse platform has defined a large number of shortcut keys.&nbsp;
 Plug-in developers should make sure that the existing shortcut keys do
 not conflict with the shortcut keys defined in the plug-in.
 <br>&nbsp;
 <br>&nbsp;
 <table border="1" cellspacing="0" cellpadding="3">
 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT><b>Key</b></td>

 <td ALIGN=LEFT><b>{Key} by itself</b></td>

 <td ALIGN=LEFT><b>SHIFT+{Key}</b></td>

 <td ALIGN=LEFT><b>CTRL+{Key}</b></td>

 <td ALIGN=LEFT><b>CTRL+SHIFT+{Key}</b></td>

 <td ALIGN=LEFT><b>ALT+{Key}</b></td>

 <td ALIGN=LEFT><b>CTRL+ALT+{Key}</b></td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>A</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Select All</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>B</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Project / Build</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(View) Bookmarks</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>C</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Copy</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>D</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>(JDT editor) Display</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>E</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>(JDT editor) Next Problem</td>

 <td ALIGN=LEFT>(JDT editor) Previous Problem</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Find / Replace</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>G</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>H</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Search</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>I</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>J</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>K</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(View) Tasks</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>L</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Go to Line</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>M</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(JDT editor) Add Import</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(JDT) Refactor / Move</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>N</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>File / New / Other</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(View) Navigator</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>O</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(JDT editor) Organize Imports</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(View) Outline</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>P</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>File / Print</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(View) Properties</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Q</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>(JDT editor) Inspect</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>R</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>S</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>File / Save</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>File / Save All</td>

 <td ALIGN=LEFT>Window / Switch to Editor</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>T</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(JDT) Open Type</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>U</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>V</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Paste</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>W</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>X</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Cut</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(JDT) Refactor / Extract method</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Y</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Redo</td>

 <td ALIGN=LEFT>(JDT) Refactor / Redo</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Z</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>Edit / Undo</td>

 <td ALIGN=LEFT>(JDT) Refactor / Undo</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Space</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=RIGHT BGCOLOR="#E3E3E3">&nbsp;</td>

 <td ALIGN=LEFT>(JDT editor) Content Assist</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Backspace</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>Windows: Undo</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Tab</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(JDT editor) Shift Right</td>

 <td ALIGN=LEFT>(JDT editor) Shift Left</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Insert</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>Windows: Paste</td>

 <td ALIGN=LEFT>Windows: Copy</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Delete</td>

 <td ALIGN=LEFT>Edit / Delete</td>

 <td ALIGN=LEFT>Windows: Cut</td>

 <td ALIGN=LEFT>Edit / Delete</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Home</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>End</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Page Up</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Page Down</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Insert</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Delete</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Hyphen (-)</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>Show System Menu</td>

 <td ALIGN=LEFT>Show View Menu</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Left Arrow</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Right Arrow</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Up Arrow</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>Down Arrow</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F1</td>

 <td ALIGN=LEFT>Help</td>

 <td ALIGN=LEFT>Help</td>

 <td ALIGN=LEFT>Help</td>

 <td ALIGN=LEFT>Help</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F2</td>

 <td ALIGN=LEFT>(Navigator view) Rename, (JDT editor) Open JavaDoc</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F3</td>

 <td ALIGN=LEFT>(JDT editor) Open on Selection</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F4</td>

 <td ALIGN=LEFT>(JDT editor) Open Type Hierarchy</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>File / Close All</td>

 <td ALIGN=LEFT>File / Close</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F5</td>

 <td ALIGN=LEFT>(Navigator view) Refresh, (Properties view) Refresh, (Debug)
 Step Into</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F6</td>

 <td ALIGN=LEFT>(Debug) Step Over</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>Next Editor</td>

 <td ALIGN=LEFT>Previous Editor</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F7</td>

 <td ALIGN=LEFT>(Debug) Run to Return</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>Next View</td>

 <td ALIGN=LEFT>Previous View</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F8</td>

 <td ALIGN=LEFT>(Debug) Resume</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F9</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F10</td>

 <td ALIGN=LEFT>(Debug) Relaunch last</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F11</td>

 <td ALIGN=LEFT>(Debug) Debug</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>(Debug) Run</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>

 <tr VALIGN=BOTTOM>
 <td ALIGN=LEFT>F12</td>

 <td ALIGN=LEFT>Activate Editor</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=LEFT>Activate Editor</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>

 <td ALIGN=RIGHT>&nbsp;</td>
 </tr>
 </table>

 <p>

 <br>
 <h2>
 <a NAME="Best Practices"></a>Best Practices</h2>
 <p>


 In this section, we provide examples of best practices for designing and implementing
 some common user interactions within the Eclipse platform.

 <p>

 <h4>
 <a NAME="BP:Syntax and Compilation Error Handling"></a>Syntax and Compilation Error Handling</h4>

 When designing editors that provide syntax or compilation checking support,
 follow the Java tooling design in the Eclipse platform.

 <p>
 Provide on the fly syntax checking if possible. Use red "squiggle" to indicate where
 the potential error is located in the source code. Use a red box on the side bar on the
 right side to indicate the approximate error position in the file. Use a prominent marker
 on the upper right hand corner to indicate that the file contains errors or warnings.
 Use red color to indicate errors, and use yellow to indicate warnings.

 <p><img src="images/bp1.gif" hspace="40" height=597 width=789>

 <p>
 After users perform a save operation, user a more prominent marker on the left hand side
 margin to indicate errors and warnings in the file. When using the mouse pointer to hover
 over the marker, the description text should be displayed. In addition, show the
 icon decorator in the content editor tab. In the tree view that shows the resource in
 the Eclipse workspace, use icon decorator to indicate errors or warnings associated
 with this resource, and propagate the icon decorator indication up to the parents
 of the resource in the tree view. Finally, an entry should be added to the Task view
 to list the errors and warnings.

 <p><img src="images/bp2.gif" hspace="40" height=597 width=789>

 <h4>
 <a NAME="BP:Coding Assistance"></a>Coding Assistance</h4>
 In addition to supporting the standard content assist in an editor, editors should
 exploit the use of Quick Fixes and Quick Assist. Use the light bulb marker on the
 left hand side margin to provide suggestions on how to fix problems with the
 source code. Users can click on the light bulb or use Edit -> Quick Fix menu item
 to invoke this command.

 <p><img src="images/bp3.gif" hspace="40" height=597 width=789>

 <p>
 Even when there are no syntax errors in the file, users should be able to obtain
 certain quick assistance with their code using the Quick Fix mechanism.
 For example, assigning an expression to a local variable.

 <p><img src="images/bp4.gif" hspace="40" height=597 width=789>


 <p><hr>
 <p>
 If an editor is used for writing code in a given programming language,
 hyper-linked code support should be enabled. While using the mouse pointer
 to hover over the source code, pressing the Ctrl key will turn the programming language
 constructs such as class, method, and field identifiers into clickable links
 to the corresponding declaration.


 <p><img src="images/bp5.gif" hspace="40" height=597 width=789>

 <p><hr>
 <p>
 When possible, a plug-in should provide refactoring support at the programming
 language or application development level. For example, if users rename a method in
 a Java class, refactoring support should enable users to automatically find and
 fix up all references. If users change the URL for a given resource in a Web
 application, refactoring support should enable users to automatically update
 the references to the modified URL.

 <p><img src="images/bp6.gif" hspace="40" height=597 width=789>


 <h4>
 <a NAME="BP:Context Menu"></a>Context Menu</h4>
 Here is one suggested process to reason why a menu item should be added or
 removed from the context menu. The objective is to reduce the number of
 context menu items to no more than 20.

 <p>
 First, remove menu items that are not sensitive to selections.
 Second, remove menu items that are not frequently used.
 Third,?examine the items that are not sensitive?to selection
 but are frequently used. Add at most of 5 of these items back.
 Fourth,?remove all disabled menu items, except for clipboard operations
 such as copy and paste, and team, compare and replace submenus.
 Fifth, remove menu items that are frequently used, selection sensitive,
 but have a dominant keyboard shortcut key defined, except for
 clipboard and save operations.


 <h4>
 <a NAME="BP:Labels, Fonts and Layout for Flat Look Design"></a>
 Labels, Fonts and Layout for Flat Look Design</h4>

 For Flat Look design, when using buttons with ellipses
 (except for the "More..." button), it should pop up a secondary window
 which can be a dialog box or a wizard.

 <p>
 Use Title capitalization for section titles.
 The distance between section columns should be 32 pixels.

 <p>
 On pages with listbox on the left hand side,
 the distance be between the list box and the right-hand column
 (e.g. showing properties for a selected listbox item) should be 10 pixels.

 <p><img src="images/flatlook7.gif" hspace="40" height=285 width=321>

 <p><hr>
 <p>

 <p>
 For labels and fields, use RGB value (160, 160, 164) for enabled state,
 RBG value (0, 0, 0) for read-only state, and RBG value (128, 128, 128) for disabled state.


 <p><img src="images/flatlook8.gif" hspace="40" height=138 width=600>

 <p>
 For listbox control, use RBG value (0, 0, 0) for the border to indicate enabled state,
 use RBG value (128, 128, 128) for disabled state.


 <p><img src="images/flatlook9.gif" hspace="40" height=368 width=384></p>

 <p>
 <h4>
 <a NAME="BP:Decorators"></a>
 Decorators</h4>

 Enabling and disabling the decorators are extremely useful when the decorations performed by two or more decorators conflict with each other. For example, the CVS plug-in might decorate the base image by superimposing the base image with a custom image while the &quot;Decorate Example&quot; plug-in might superimpose a different custom image at the same position thereby conflicting with the CVS plug-in decoration. If the decoration performed by two different decorators on the same resource conflict, users should appropriately enable / disable different decorators to get the required decoration.
 <p>
 Implementation tip:<br>
 It is very important to design custom decorators that don't conflict with basic decorations provided by different Eclipse views. For example, the package explorer view decorates Java files with problem markers (a problem marker is placed at the bottom left hand corner) if there are compilation errors. It is a bad practice to decorate resources with custom decoration exactly at the position of a problem marker and developers should avoid this. If the custom decoration is performed at the bottom left corner, then custom decoration and the problem marker decoration, if any, conflict each other and hence users will not be able to view the decorations. The solution to the above mentioned problem is to provide a custom image decoration at the bottom right corner which does not conflict with the basic image decoration provided by Eclipse. The top left corner is the second best place although it conflicts with the binary project decorator. The bottom left and top right should be avoided as they are decorated outside of the decorator mechanism
 <BR>
 <p>

 <br>
 <h2>
 <a NAME="Checklist For Developers"></a>Checklist For Developers</h2>
 Here is a checklist for developers who are developing UI plugins.&nbsp;
 This <i>could</i> be used for certification purposes.
 <br>&nbsp;


 <h3>General UI Guidelines</h3>

 <h4>The Spirit of Eclipse</h4>

 <p><img src="images/guidelineCheckbox.gif"" height="16" width="16">
 <font color="#09448D"><b>Guideline 1.1</b></font>
 <blockquote><font color="#09448D">Follow and apply good user interface
 design principles: user in control, directness, consistency, forgiveness,
 feedback, aesthetics, and simplicity.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.2</font></b>
 <blockquote><font color="#006699">Follow the platform lead for user interface
 conventions.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.3</font></b>
 <blockquote><font color="#09448D">Be careful not to mix UI metaphors.&nbsp;
 It may blur the original concept, and your own application.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.4</font></b>
 <blockquote><font color="#09448D">If you have an interesting idea, work
 with the Eclipse community to make Eclipse a better platform for all.</font></blockquote>
 </p>


 <h4>Capitalization</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 1.5</font></b>
 <blockquote><font color="#09448D">Use Headline style capitalization for
 menus,  tooltip and all titles, including those used for windows, dialogs, tabs, column headings
 and push buttons. Capitalize the first and last words, and all nouns, pronouns,
 adjectives, verbs and adverbs.&nbsp; Do not include ending punctuation.</font></blockquote>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.6</font></b>
 <blockquote><font color="#09448D">Use Sentence style capitalization for
 all control labels in a dialog or window, including those for check boxes,
 radio buttons, group labels, and simple text fields.&nbsp; Capitalize the
 first letter of the first word, and any proper names such as the word Java.</font></blockquote>
 </p>


 <h4>Language</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 1.7</font></b>
 <blockquote><font color="#09448D">Create localized version of the resources within your plug-in.</font></blockquote>
 </p>


 <h4>Error Handling</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 1.8</font></b>
 <blockquote><font color="#09448D">When an error occurs which requires either
 an explicit user input or immediate attention from users, communicate the
 occurrence with a modal dialog.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 1.9</font></b>
 <blockquote><font color="#09448D">If a programming error occurs in the
 product, communicate the occurrence with a dialog, and log it.</font></blockquote>
 </p>

 <br>
 <h3>Visual Design</h3>

 <h4>Consistency</h4>
 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.1</font></b>
 <blockquote><font color="#09448D">Re-use the core visual concepts to maintain consistent representation and meaning
 across Eclipse plug-ins.</font></blockquote></p>


 <h4>Icon Palettes</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.2</font></b>
 <blockquote><font color="#09448D">Use the Eclipse 256 color palette for creating the active or selected state of
 all icon types.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.3</font></b>
 <blockquote><font color="#09448D">Use the Eclipse 8 color palette for creating the enabled state of perspective,
 view, toolbar, toolbar wizard, and local toolbar icons.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.4</font></b>
 <blockquote><font color="#09448D">Use the Eclipse 2 color palette for creating the disabled state of toolbar,
 toolbar wizard, and local toolbar icons.</font></blockquote></p>


 <h4>Icon Types</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.5</font></b>
 <blockquote><font color="#09448D">Use the appropriate icon type in the location it is designed for within the
 user interface.</font></blockquote></p>


 <h4>Icon Size &amp; Placement</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.6</font></b>
 <blockquote><font color="#09448D">Follow the specific size specifications for each type of icon.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.7</font></b>
 <blockquote><font color="#09448D">Cut the icons with the specific placement shown to ensure alignment in the user interface.</font></blockquote></p>


 <h4>Icon Positioning</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.8</font></b>
 <blockquote><font color="#09448D">Follow the positioning guidelines for the different types of icons for optimal alignment
 of these elements relative to one another.</font></blockquote></p>


 <h4>Icon Positioning</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.9</font></b>
 <blockquote><font color="#09448D">Use the Eclipse special blue 183 color palette for creating wizard graphics.</font></blockquote></p>


 <h4>Wizard Size &amp; Placement</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.10</font></b>
 <blockquote><font color="#09448D">Follow the specific size specifications for wizard graphics.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.11</font></b>
 <blockquote><font color="#09448D">Cut the wizard graphics with the specific placement shown to ensure alignment
 in the wizard banner area.</font></blockquote></p>


 <h4>Implementation Conventions</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.12</font></b>
 <blockquote><font color="#09448D">Follow the predefined directory structure and naming convention.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.13</font></b>
 <blockquote><font color="#09448D">Keep the original directory names provided.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.14</font></b>
 <blockquote><font color="#09448D">Minimize duplication of graphics within a plugin by keeping all graphics in one, or few, first level user interface directories.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.15</font></b>
 <blockquote><font color="#09448D">Use the active, enabled, and disabled states provided.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.16</font></b>
 <blockquote><font color="#09448D">Abbreviate file name instead of using the full icon name,
 e.g. New Interface becomes "newint".</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.17</font></b>
 <blockquote><font color="#09448D">Use lower case characters in your file names, e.g. DTD becomes "dtd".</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.18</font></b>
 <blockquote><font color="#09448D">Use 10 characters or less in your file names if possible (underscores count as a character).</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.19</font></b>
 <blockquote><font color="#09448D">Use a file name suffix that describes its location or function in the tool,
 e.g. newint_wiz.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.20</font></b>
 <blockquote><font color="#09448D">Use transparent *.gif format for all user interface icons and wizard graphics,
 unless the context requires a different file format.</font></blockquote></p>


 <p><img src="images/guidelineCheckbox.gif" height="16" width="16">
 <b><font color="#09448D">&nbsp;Guideline 2.21</font></b>
 <blockquote><font color="#09448D">Keep the original file names provided.</font></blockquote></p>


 <br>
 <h3>Component Development</h3>

 <h4>Commands</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 3.1</font></b>
 <blockquote><font color="#09448D">Each command must have a label, tool tip,
 and full color image.&nbsp; The label and tool tip must use Headline style
 capitalization.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 3.2</font></b>
 <blockquote><font color="#09448D">The command tooltip should describe the
 result of the command, not the current state of the command. Use the text same as that for the command label.</font></blockquote>

 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 3.3</font></b>
 <blockquote><font color="#09448D">Adopt the labeling terminology of the
 workbench for New, Delete and Add commands.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 3.4</font></b>
 <blockquote><font color="#09448D">A command should only be enabled if it
 can be completed successfully.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 3.5</font></b>
 <blockquote><font color="#09448D">Command enablement should be quick.&nbsp;
 If command enablement cannot be quick, enable the command optimistically
 and display an appropriate message if the command is invoked, but cannot
 be completed.</font></blockquote>
 </p>


 <h4>Dialogs</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 4.1</font></b>
 <blockquote><font color="#09448D">When a dialog opens, set the initial
 focus to the first  input control in the container. If there are no input controls, the initial focus should
 be assigned to the default button.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">
 Guideline 4.2</font></b>
 <blockquote><font color="#09448D">Slush Bucket widget (or Twin Box) should
 flow from left to right with the source objects on the left hand side.
 It should have the >, &lt;, >>, &lt;&lt; control buttons in this order.</font></blockquote>
 </p>


 <h4>Wizards</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.1</font></b>
 <blockquote><font color="#09448D">Use a wizard for any task consisting
 of many steps, which must be completed in a specific order.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.2</font></b>
 <blockquote><font color="#09448D">Each wizard must contain a header with
 a banner graphic and a text area for user feedback.&nbsp; It must also
 contain Back, Next, Finish, and Cancel buttons in the footer.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.3</font></b>
 <blockquote><font color="#09448D">Start the wizard with a prompt, not an
 error message.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.4</font></b>
 <blockquote><font color="#09448D">Seed the fields within the wizard using
 the current workbench state.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.5</font></b>
 <blockquote><font color="#09448D">Validate the wizard data in tab order.&nbsp;
 Display a prompt when information is absent, and an error when information
 is invalid.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.6</font></b>
 <blockquote><font color="#09448D">Only enable the Next / Finish buttons
 if all required information in the dialog is present and valid.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.7</font></b>
 <blockquote><font color="#09448D">Remove all programming message ID's from
 wizard text.</font></blockquote>

 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.8</font></b>
 <blockquote><font color="#09448D">Use a Browse Button whenever an existing
 object is referenced in a wizard.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.9</font></b>
 <blockquote><font color="#09448D">If a new file is created, open the file
 in an editor.&nbsp; If a group of files are created, open the most important,
 or central file in an editor. Open the readme.html file upon creation of
 an example project.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.10</font></b>
 <blockquote><font color="#09448D">If a new project is created, prompt users and change the
 active perspective to suit the project type.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.11</font></b>
 <blockquote><font color="#09448D">If a new object is created, select and
 reveal the new object in the appropriate view.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.12</font></b>
 <blockquote><font color="#09448D">Create folder objects in a wizard if
 reasonable defaults can be defined.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 5.13</font></b>
 <blockquote><font color="#09448D">Use the term "Project name" for the input field label when the
 item must be a Project; otherwise, use the term "Folder name". Do not qualify
 the term.</font></blockquote>
 </p>


 <h4>Editors</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.1</font></b>
 <blockquote><font color="#09448D">Use an editor to edit or browse a file,
 document, or other primary content.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.2</font></b>
 <blockquote><font color="#09448D">Modifications made in an editor must
 follow an open-save-close lifecycle model.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.3</font></b>
 <blockquote><font color="#09448D">Only one instance of an editor may exist,
 for each editor input, within a perspective.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.4</font></b>
 <blockquote><font color="#09448D">It must be possible to open a separate
 instance of an editor for each different input.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.5</font></b>
 <blockquote><font color="#09448D">The editor should be labeled with the
 name of the file, document, or input being edited.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.6</font></b>
 <blockquote><font color="#09448D">In multipage editors, use a tab control
 for page activation.Tab labels should be kept to one word, and two words
 at most.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.7</font></b>
 <blockquote><font color="#09448D">All of the commands, except for the obvious commands, available in the editor
 should be added to the window menu bar.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.8</font></b>
 <blockquote><font color="#09448D">Use the standard format for editor contributions
 in the window menu bar.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.9</font></b>
 <blockquote><font color="#09448D">If an editor has support for Cut, Copy,
 Paste, or any of the global commands, these commands must be executable from
 the same commands in the window menu bar and toolbar.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.10</font></b>
 <blockquote><font color="#09448D">Fill the editor toolbar with the most
 commonly used items in the view menu.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.11</font></b>
 <blockquote><font color="#09448D">Fill the context menu with selection
 oriented commands.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.12</font></b>
 <blockquote><font color="#09448D">Use the standard format for editor context
 menus.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.13</font></b>
 <blockquote><font color="#09448D">Fill the context menu with a fixed set
 of commands for each selection type, and then enable or disable each to
 reflect the selection state.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.14</font></b>
 <blockquote><font color="#09448D">Register all context menus in the editor
 with the platform.</font></blockquote>
 </p>

 <img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.15</font></b>
 <blockquote><font color="#09448D">Implement a Command Filter for each object
 type in the editor.</font></blockquote>

 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.16</font></b>
 <blockquote><font color="#09448D">If the input to an editor is deleted,
 and the editor contains no changes, the editor should be closed.</font></blockquote>

 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.17</font></b>
 <blockquote><font color="#09448D">If the input to an editor is deleted,
 and the editor contains changes, the editor should give the user a chance
 to save their changes to another location, and then close.</font></blockquote>

 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.18</font></b>
 <blockquote><font color="#09448D">If the resource is dirty, prefix the resource
 name presented in the editor tab with an asterisk.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.19</font></b>
 <blockquote><font color="#09448D">Treat read-only editor input as you would
 any other input.&nbsp; Enable the Save As if possible. Display "Read-only"
 in the status bar area.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.20</font></b>
 <blockquote><font color="#09448D">If the data within an editor is too extensive
 to see on a single screen, and will yield a structured outline, the editor
 should provide an outline model to the Outline view.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.21</font></b>
 <blockquote><font color="#09448D">Notification about location between an
 editor and the Outline view should be two-way. A context menu should be available
 in the Outline view as appropriate.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.22</font></b>
 <blockquote><font color="#09448D">An error or warning image should be added
 to items with the error or warning respectively. A container should have a red X if it there are errors on the container itself, a gray X if any of its descendents have errors (but not the container itself), and no X if neither the container nor any of its descendents have errors.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.23</font></b>
 <blockquote><font color="#09448D">If appropriate, implement the "Add Task"
 feature in your editor.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.24</font></b>
 <blockquote><font color="#09448D">If appropriate, implement the "Add Bookmark"
 feature in your editor.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.25</font></b>
 <blockquote><font color="#09448D">Editors with source lines of text should show the current line and optionally column numbers  the status line. It's optional for the editor to show line numbers for each line in the editor itself.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.26</font></b>
 <blockquote><font color="#09448D">Table cell editors should support the
 single-click activation model, and in edit mode, they should render complex
 controls upon single-click.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.27</font></b>
 <blockquote><font color="#09448D">Changes made in a table cell editor should
 be committed when a user clicks off the cell or hits the "Enter" key. Selection
 should be cancelled when user hits the "Esc" key.First letter navigation
 should be supported as a cursoring mechanism within a cell.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.28</font></b>
 <blockquote><font color="#09448D">When performing fine-grain error validation
 in an editor, use red squiggles to underline the invalid content. When users move the mouse over the red squiggles, display the error text in a fly-over pop up box.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.29</font></b>
 <blockquote><font color="#09448D">Use the Task view to show errors found
 when the Save command is invoked.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 6.30</font></b>
 <blockquote><font color="#09448D">If modifications to a resource are made
 outside of the workbench, users should be prompted to either override the
 changes made outside of the workbench, or back out of the Save operation
 when the Save command is invoked in the editor.</font></blockquote>
 </p>


 <h4>Views</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.1</font></b>
 <blockquote><font color="#09448D">Use a view to navigate a hierarchy of
 information, open an editor, or display the properties of an object.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.2</font></b>
 <blockquote><font color="#09448D">Modifications made within a view must
 be saved immediately.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.3</font></b>
 <blockquote><font color="#09448D">Only one instance of a view may exist
 in a perspective.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.4</font></b>
 <blockquote><font color="#09448D">A view must be able to be opened in more than one perspective.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.5</font></b>
 <blockquote><font color="#09448D">A view can be opened from the Window
 > Show View menu.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.6</font></b>
 <blockquote><font color="#09448D">The view label in the title bar must
 be prefixed with the label of the view in the Perspective > Show View menu.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.7</font></b>
 <blockquote><font color="#09448D">If a view contains more than one control,
 it may be advisable to split it up into two or more views.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.8</font></b>
 <blockquote><font color="#09448D">When a view first opens, derive the view
 input from the state of the perspective.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.9</font></b>
 <blockquote><font color="#09448D">If a view displays a resource tree, consider
 using the window input as the root of visible information in the view.</font></blockquote>
 </p>

 </P><p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.10</font></b>
 <blockquote><font color="#09448D">Use the view pulldonw menu for presentation commands, not
 selection-oriented commands.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.11</font></b>
 <blockquote><font color="#09448D">Use the standard order of commands for view pulldown
 menus.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.12</font></b>
 <blockquote><font color="#09448D">Put only the most commonly used commands on the toolbar.  Any command on a toolbar must also appear in a menu, either the context menu or the view menu.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.13</font></b>
 <blockquote><font color="#09448D">Fill the context menu with selection
 oriented actions, not presentation actions.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.14</font></b>
 <blockquote><font color="#09448D">Use the standard  order of commands for view context
 menus.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.15</font></b>
 <blockquote><font color="#09448D">Fill the context menu with a fixed set
 of commands for each selection type, and then enable or disable each to
 reflect the selection state.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.16</font></b>
 <blockquote><font color="#09448D">If an object appears in more than one
 view, it should have the same context menu in each.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.17</font></b>
 <blockquote><font color="#09448D">Register all context menus in the view
 with the platform.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.18</font></b>
 <blockquote><font color="#09448D">Implement a Command Filter for each object
 type in the view.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.19</font></b>
 <blockquote><font color="#09448D">If a view has support for Cut, Copy,
 Paste, or any of the global commands, these commands must be executable from
 the same commands in the window menu bar and toolbar.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 7.20</font></b>
 <blockquote><font color="#09448D">Persist the state of each view between
 sessions.</font></blockquote>
 </p>

 <P><img src="images/guidelineCheckbox.gif" height="16" width="16"><B><font color="#09448D">&nbsp;Guideline
 7.21</FONT></B></P><BLOCKQUOTE><FONT color="#09448D"><FONT color="#000000"></FONT>
 Navigation views should support &quot;Link with Editor&quot; on the view menu<FONT color="#000000"></FONT>
 </FONT></BLOCKQUOTE>
 </P>


 <h4>Perspectives</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.1</font></b>
 <blockquote><font color="#09448D">Create a new perspective type for long
 lived tasks, which involve the performance of smaller, non-modal tasks.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.2</font></b>
 <blockquote><font color="#09448D">If you just want to expose a single view,
 or two, extend an existing perspective type.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.3</font></b>
 <blockquote><font color="#09448D">The size and position of each view in
 a perspective should be defined in a reasonable manner, such that the user
 can resize or move a view if they desire it. When defining the initial layout, it is important to consider the overall flow between the views (and editors) in the perspective.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.4&nbsp;</font></b>
 <blockquote><font color="#09448D">If a perspective has just one part, it
 may be better suited as a view or editor.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.5</font></b>
 <blockquote><font color="#09448D">If it is undesirable to have an editor
 area in a perspective, hide it.&nbsp; Do not resize the editor area to
 the point where it is no longer visible.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.6</font></b>
 <blockquote><font color="#09448D">Populate the window menu bar with commands
 and command sets which are appropriate to the task orientation of the perspective,
 and any larger workflow.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.7 </font></b>
 <blockquote><font color="#09448D">A new perspective should be opened only
 if the user explicitly states a desire to do so.&nbsp; In making this statement,
 the user agrees to leave their old context, and create a new one.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.8</font></b>
 <blockquote><font color="#09448D">If a new perspective is opened as a side
 effect of another command, the user should be able to turn this behavior
 off.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.9</font></b>
 <blockquote><font color="#09448D">If a new perspective is opened, it should
 be opened within the current window, or in a new window, depending
 on the user preference.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 8.10</font></b><blockquote><font color="#09448D">The list of shortcuts added to the New,
 Open Perspective, and Show View menus should be at most 7 plus / minus
 2 items.</font></blockquote>
 </p>


 <h4>Windows</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.1</font></b>
 <blockquote><font color="#09448D">Use an Action Set to contribute actions
 to the window menu bar and toolbar.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.2</font></b>
 <blockquote><font color="#09448D">Follow the platform lead when distributing
 actions within an Action Set.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.3</font></b>
 <blockquote><font color="#09448D">Contribute actions to the window menu
 bar first, and then to the window toolbar if they will be frequently used.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.4</font></b>
 <blockquote><font color="#09448D">Define each action set with a specific
 task in mind.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.5</font></b>
 <blockquote><font color="#09448D">An action set should contain the smallest
 possible semantic chunking of actions. Avoid the temptation to provide
 only one action set for an entire plug-in.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.6</font></b>
 <blockquote><font color="#09448D">Use an action set to share a set of actions
 which are useful in two or more views or editors.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.7</font></b>
 <blockquote><font color="#09448D">Let the user control the visible action
 sets.&nbsp; Don't try to control it for them.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.8</font></b>
 <blockquote><font color="#09448D">"Open Object" actions must appear in
 the Navigate pulldown menu of the window.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 9.9</font></b>
 <blockquote><font color="#09448D">Always use the global status bar to display
 status related messages.</font></blockquote>
 </p>


 <h4>Properties</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 10.1</font></b>
 <blockquote><font color="#09448D">Use the Properties view to edit the properties
 of an object when quick access is important, and you will switch quickly
 from object to object.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 10.2</font></b>
 <blockquote><font color="#09448D">Use a Properties Dialog to edit the properties
 of an object which are expensive to calculate.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 10.3</font></b>
 <blockquote><font color="#09448D">&nbsp;Use a Properties Dialog to edit
 the properties of an object which contain complex relationships to one
 another.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 10.4</font></b>
 <blockquote><font color="#09448D">&nbsp;Properties Dialog should contain
 the superset of items shown in the Properties view.</font></blockquote>
 </p>


 <h4>Widgets</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 11.1</font></b>
 <blockquote><font color="#09448D">For Tree and Table widgets that have a checkbox associated
 with a cell item, changing the current selection should not automatically change
 the check state of the selected item. However, the current selection should be set
 to a given item when its check state is changed.</font></blockquote>
 </p>

 <br>
 <h3>Standard Components</h3>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 12.1</font></b>
 <blockquote><font color="#09448D">If appropriate, add actions to standard
 components of Eclipse using the plug-in registry.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 12.2</font></b>
 <blockquote><font color="#09448D">If you subclass or copy any of the standard
 components, always carry over the standard components' characteristics.</font></blockquote>
 </p>


 <h4>The Navigator View</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 13.1</font></b>
 <blockquote><font color="#09448D">Add actions to the Navigator View menu,
 toolbar, and context menu using the plug-in registry.</font></blockquote>
 </p>

 <img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 13.2</font></b>
 <blockquote><font color="#09448D">Use the attributes defined in IResourceActionFilter.java&nbsp;
 and IProjectActionFilter.java to control the visibility of context menu
 actions in the Navigator.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 13.3</font></b>
 <blockquote><font color="#09448D">Use a "Navigate -&gt; Show In Navigator" command in each
 view, to link resources back to the Navigator.</font></blockquote>
 </p>


 <h4>The Tasks View</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 14.1</font></b>
 <blockquote><font color="#09448D">Add markers (tasks, errors and warnings)
 to the Tasks view using the Marker Manager services from the Core Resources
 Management plugin.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 14.2</font></b>
 <blockquote><font color="#09448D">The description text of each marker should
 be short and concise, so that it will fit in the status line of Eclipse.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 14.3</font></b>
 <blockquote><font color="#09448D">Add actions to the Tasks view menu, toolbar,
 and context menu using the plug-in registry.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 14.4</font></b>
 <blockquote><font color="#09448D">Use the attributes defined in IMarkerActionFilter.java
 to control the visibility of context menu actions in the Tasks view.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 14.5</font></b>
 <blockquote><font color="#09448D">Support F1 keyboard command and link it
 to an infopop that gives a detailed description of the selected item in
 the Task view.</font></blockquote>
 </p>


 <h4>The Preference Dialog</h4>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 15.1</font></b>
 <blockquote><font color="#09448D">Global options should be exposed within
 the Preferences Dialog.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 15.2</font></b>
 <blockquote><font color="#09448D">Expose the preferences for a particular
 view, editor or window in the view itself, via a menu or tool item.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 15.3</font></b>
 <blockquote><font color="#09448D">Start out with a single preference page.&nbsp;
 Then evolve to more if you need to.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 15.4</font></b>
 <blockquote><font color="#09448D">If you create a preference group, use
 the root page for frequently used preferences, or those preferences which
 have wide spread effect.&nbsp; Specialize within the sub pages. The root
 preference page should not be blank.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 15.5</font></b>
 <blockquote><font color="#09448D">Attempt to integrate plug-in preferences,
 wizards, and views into existing categories for a new plug-in first, before
 considering the creation of a new category.</font></blockquote>
 </p>

 <br>
 <h3>Flat Look Design</h3>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 16.1</font></b>
 <blockquote><font color="#09448D">Use Flat Look design for user scenarios that involves
 extensive property and configuration editing.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 16.2</font></b>
 <blockquote><font color="#09448D">Have the core sections on the overview page expanded,
 and provide a "Home" icon on other pages to take users back to the overview page.</font></blockquote>
 </p>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="##09448D">&nbsp;Guideline
 16.3</font></b>
 <blockquote><font color="#09448D">Use grouping elements corresponding to tabs
 in the Flat Look content editor for the organization of the tree view in outline view.
 </font></blockquote>
 </p>


 <br>
 <h3>The Tao of Resource</h3>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 17.1</font></b>
 <blockquote><font color="#09448D">Expose the resource for resource equivalent
 model objects using an IContributorResourceAdapter.</font></blockquote>
 </p>


 <br>
 <h3>Accessibility</h3>

 <p><img src="images/guidelineCheckbox.gif" height="16" width="16"><b><font color="#09448D">&nbsp;Guideline
 18.1</font></b>
 <blockquote><font color="#09448D">All of the features provided by a tool
 should be accessible using a mouse or the keyboard.</font></blockquote>
 </p>


 <br>
 <h2>
 <a NAME="Glossary"></a>Glossary</h2>

 <P>
 <dl>
 <dt>
 <b>Command</b></dt>

 <dd>
 A <i>command</i>, which is invoked by a user to carry out some specific functions, may appear as an item in a menu, or an item in a toolbar.  In reflection of this, it has attributes for the menu or tool item label, tooltip, and image.
 As a plug-in developer, you can contribute commands to the window menu bar and toolbar, or to individual views and editors.  Contribution to the window is performed using an <i>action set</i>, a set of task oriented commands which the user can show or hide.  Contribution to a view or editor is performed using individual command.
 </dd>

 <br>&nbsp;
 <dt>
 <b>Bookmarks View</b></dt>

 <dd>
 A view used to browse the bookmarks in the workbench.</dd>

 <br>&nbsp;
 <dt>
 <b>Editor</b></dt>

 <dd>
 An editor is a visual component within a workbench page. It is typically
 used to edit or browse a document or input object. The input is identified
 using an &lt;code>IEditorInput&lt;/code>.&nbsp; Modifications made in an
 editor part follow an open-save-close lifecycle model (in contrast to a
 view part, where modifications are saved to the workbench immediately).</dd>

 <br>&nbsp;
 <dt>
 <b>File</b></dt>

 <dd>
 An object in the workspace, analogous to files in the file system.</dd>

 <br>&nbsp;
 <dt>
 <b>Folder</b></dt>

 <dd>
 A container for files in the workspace.</dd>

 <br>&nbsp;
 <dt>
 <b>Navigator View</b></dt>

 <dd>
 A view used to browse the files in the workspace</dd>

 <br>&nbsp;
 <dt>
 <b>Outline View</b></dt>

 <dd>
 A view, commonly used to view the outline of the active editor.</dd>

 <br>&nbsp;
 <dt>
 <b>Perspective</b></dt>

 <dd>
 A perspective is a visual container for a set of views and editors (parts).&nbsp;
 These parts exist wholly within the perspective and are not shared.&nbsp;
 A perspective is also like a page within a book.&nbsp; It exists within
 a window along with any number of other perspectives and, like a page within
 a book, only one perspective is visible at any time.</dd>

 <br>&nbsp;
 <dt>
 <b>Platform</b></dt>

 <dd>
 A generic framework for the integration of tools.</dd>

 <br>&nbsp;
 <dt>
 <b>Preferences</b></dt>

 <dd>
 A Preference Page is used to edit the preferences for a feature in the
 platform.</dd>

 <br>&nbsp;
 <dt>
 <b>Project</b></dt>

 <dd>
 A group of files and folders within the workspace.&nbsp; Each project maps
 to a corresponding user specified directory in the file system.</dd>

 <br>&nbsp;
 <dt>
 <b>Properties View</b></dt>

 <dd>
 A view, typically used to browse the properties for an object in the active
 editor or view.</dd>

 <br>&nbsp;
 <dt>
 <b>Properties Dialog</b></dt>

 <dd>
 A dialog for editing the properties of an object.</dd>

 <br>&nbsp;
 <dt>
 <b>Property Page</b></dt>

 <dd>
 A page within a Properties Dialog.</dd>

 <br>&nbsp;
 <dt>
 <b>Resource</b></dt>

 <dd>
 The generic name for projects, folders and files.</dd>

 <br>&nbsp;
 <dt>
 <b>Tasks View</b></dt>

 <dd>
 A view used to browse the tasks, errors, and warnings within the workspace.</dd>

 <br>&nbsp;
 <dt>
 <b>View</b></dt>

 <dd>
 A view is a visual component within a workbench page.&nbsp; It is typically
 used to navigate a hierarchy of information (like the workspace), open
 an editor, or display properties for the active editor.&nbsp; Modifications
 made in a view are saved immediately (in contrast to an editor part, which
 conforms to a more elaborate open-save-close lifecycle).</dd>

 <br>&nbsp;
 <dt>
 <b>Wizard</b></dt>

 <dd>
 A Wizard is typically used to create new resources, import resources, or
 export resources.</dd>

 <br>&nbsp;
 <dt>
 <b>Workbench</b></dt>

 <dd>
 The Workbench provides the user interface structure for Eclipse. The purpose
 of the Workbench is to facilitate the seamless integration of tools. These
 tools contribute to extension points defined by the Workbench.&nbsp; The
 Workbench is responsible for the presentation and coordination of the user
 interface.</dd>

 <br>&nbsp;
 <dt>
 <b>Workspace</b></dt>

 <dd>
 The various tools plugged in to the Eclipse Platform operate on regular
 files in the user's workspace.&nbsp; The workspace consists of one or more
 top level projects, where each project maps to a corresponding user specified
 directory in the file system.&nbsp; Each project contains a collection
 of folders and files.</dd>
 </dl>

 <br>

 <h2>
 <a NAME="Acknowledgement"></a>Acknowledgement</h2>
 Screenshots contributed to Eclipse.org and used in this document,
 originate from plugins released or under development by the following teams:
 <p>
 <ul>
 <li>
 Java Development Tooling, Eclipse Subproject</li>
 <li>
 WebSphere&reg; Studio Application Developer, IBM Corporation</li>
 <li>
 Rational XDE Professional,  IBM Corporation.</li>
 </ul>
 <p>By agreeing to share selected elements of their user interface designs
 (both positive and negative), we feel that these teams have helped make
 the UI guidelines stronger.
 <br>

 <h2>
 <a NAME="Revision"></a>Revision History</h2>
 <p>This covers the more significant changes to the guidelines since Version 1.0:</p>
 <table class="indent" border="1" cellspacing="0" cellpadding="5" width="90%"">

 	<tr>
 		<td rowspan="5" valign="top"><h4>Added</h4></td>
 		<td>General UI Principles : "Decorators" subsection</td>
 	</tr>
 	<tr>
 		<td>"Visual Design" section covers consistency, design and implementation issues for UI graphics</td>
 	</tr>
 	<tr>
 		<td>Component Development : "Widgets" subsection describes some of the recommended designs for Standard
 		Windows Toolkit (SWT) widgets</td>
 	</tr>
 	<tr>
 		<td>"Flat Look Design" section for user scenarios that involve extensive property and configuration editing</td>
 	</tr>
 	<tr>
 		<td>"Best Practices" section provides examples of best practices for designing and implementing some
 		common user interactions</td>
 	</tr>

 	<tr>
 		<td rowspan="2" valign="top"><h4>Removed</h4></td>
 		<td>Component Development : Perspectives : Opening a perspective in code - Guideline "Consider replacing the
 		perspective type before you open a new perspective" has been removed</td>
 	</tr>
 	<tr>
 		<td>Component Development : Windows : Actions - "Open Application" has been removed</td>
 	</tr>

 	<tr>
 		<td rowspan="2" valign="top"><h4>Modified</h4></td>
 		<td>Anything referred to as an "action" in Version 1.0 of the guidelines has been changed to "command" in
 		Version 2.1 of the guidelines</td>
 	</tr>
 	<tr>
 		<td>The full guideline document has been reformatted and the graphical presentation has been updated</td>
 	</tr>
 </table>


 <p>
 <hr WIDTH="100%">
 <div align="center"><br>
   Version 2.1 February 2004 <br>
 <br>Copyright&copy; 2001 - 2004 International Business Machine Corporation.
 <br>Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
 <br>Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.</div>
 </p>
 <br>
 </body>
 </html>