Naming Conventions

Naming Conventions
From Eclipsepedia
Contents
•
1 General
o
1.1 Eclipse Workspace Projects
o
1.2 Java Packages
o
1.3 API Packages
o
1.4 Internal Implementation Packages
o
1.5 Test Suite Packages
o
1.6 Examples Packages
o
1.7 Additional rules
•
2 Classes and Interfaces
•
3 Methods
•
4 Variables
•
5 Constants
•
6 Plug-ins and Extension Points
•
7 System Files and Settings

General
Like other open source projects, the code base for the Eclipse project should avoid using
names that reference a particular company or their commercial products.
Eclipse Workspace Projects
When Eclipse is being used to develop plug-ins for the Eclipse project, the name of the
Eclipse workspace project should match the name of the plug-in. For example,
org.eclipse.core.runtime plug-in is developed in an Eclipse workspace project named
org.eclipse.core.runtime.
Java Packages
The Eclipse Platform consists of a collection of Java packages. The package namespace
is managed in conformance with Sun's package naming guidelines; subpackages should
not be created without prior approval from the owner of the package subtree. The
packages for the open-source Eclipse project are all subpackages org.eclipse.
The first package name segment after org.eclipse is generally the subproject name,
followed by the component name.
org.eclipse.<subproject>.<component>[.*]- General form of package
names
The following subprojects are assigned at the time of writing:
org.eclipse.jdt.<component>[.*] - Java development tooling
org.eclipse.pde.<component>[.*] - Plug-in development environment
The following package name segments are reserved:
internal - indicates an internal implementation package that
contains no API
tests - indicates a non-API package that contains only test suites
examples - indicates a non-API package that contains only examples
These name are used as qualifiers and appear between the subproject and component
name:
org.eclipse.<subproject>.internal.<component>[.*] - internal package
org.eclipse.<subproject>.tests.<component>[.*] - tests
org.eclipse.<subproject>.examples.<component>[.*] - examples

In the case of the Eclipse Platform proper, there is no subproject name, and the qualifiers
appear immediately after the component name:
org.eclipse.<component>[.*] - Eclipse Platform proper
org.eclipse.<component>.internal[.*] - Eclipse Platform internal
package
org.eclipse.<component>.tests[.*] - Eclipse Platform tests
org.eclipse.<component>.examples[.*] - Eclipse Platform examples
The following components of the Eclipse Platform proper are assigned at the time of
writing:
org.eclipse.ant[.*] - Ant support
org.eclipse.compare[.*] - Compare support
org.eclipse.core[.*] - Platform core
org.eclipse.debug[.*] - Debug
org.eclipse.help[.*] - Help support
org.eclipse.jdi[.*] - Eclipse implementation of Java Debug Interface
(JDI)
org.eclipse.jface[.*] - JFace
org.eclipse.platform[.*] - Documentation
org.eclipse.scripting[.*] - Scripting support
org.eclipse.sdk[.*] - SDK configuration
org.eclipse.search[.*] - Search support
org.eclipse.swt[.*] - Standard Widget Toolkit
org.eclipse.ui[.*] - Workbench
org.eclipse.update[.*] - Plug-in live update
org.eclipse.vcm[.*] - Version and Configuration Management
org.eclipse.webdav[.*] - WebDAV support
For example,
org.eclipse.jdt.internal.core.compiler - Correct usage
org.eclipse.jdt.core.internal.compiler - Incorrect. internal should
immediately follow subproject name.

org.eclipse.core.internal.resources - Correct usage
org.eclipse.internal.core.resources - Incorrect. internal should
never immediately follow org.eclipse.
org.eclipse.core.resources.internal - Incorrect. internal should
immediately follow Eclipse Platform component name.
API Packages
API packages are ones that contain classes and interfaces that must be made available to
ISVs. The names of API packages need to make sense to the ISV. The number of
different packages that the ISV needs to remember should be small, since a profusion of
API packages can make it difficult for ISVs to know which packages they need to import.
Within an API package, all public classes and interfaces are considered API. The names
of API packages should not contain internal, tests, or examples to avoid confusion with
the scheme for naming non-API packages.
Internal Implementation Packages
All packages that are part of the platform implementation but contain no API that should
be exposed to ISVs are considered internal implementation packages. All implementation
packages should be flagged as internal, with the tag occurring just after the major
package name. ISVs will be told that all packages marked internal are out of bounds. (A
simple text search for ".internal." detects suspicious reference in source files; likewise,
"/internal/" is suspicious in .class files).
Test Suite Packages
All packages containing test suites should be flagged as tests, with the tag occurring just
after the major package name. Fully automated tests are the norm; so, for example,
org.eclipse.core.tests.resources would contain automated tests for API in
org.eclipse.core.resources. Interactive tests (ones requiring a hands-on tester) should be
flagged with interactive as the last package name segment; so, for example,
org.eclipse.core.tests.resources.interactive would contain the corresponding interactive
tests.
Examples Packages
All packages containing examples that ship to ISVs should be flagged as examples, with

the tag occurring just after the major package name. For example,
org.eclipse.swt.examples would contain examples for how to use the SWT API.
Additional rules
•
Package names should contain only lowercase ASCII alphanumerics, and avoid
underscore _ or dollar sign $ characters.
Classes and Interfaces
Sun's naming guidelines states
Class names should be nouns, in mixed case with the first letter of each internal
word capitalized. Try to keep your class names simple and descriptive. Use whole
words - avoid acronyms and abbreviations (unless the abbreviation is much more
widely used than the long form, such as URL or HTML).
Examples:
•
class Raster;
•
class ImageSprite;
Interface names should be capitalized like class names.
For interface names, we follow the "I"-for-interface convention: all interface names are
prefixed with an "I". For example, "IWorkspace" or "IIndex". This convention aids code
readability by making interface names more readily recognizable.
Additional rules:
The names of exception classes (subclasses of Exception) should follow the
common practice of ending in "Exception".
Methods
Sun's naming guidelines states
Methods should be verbs, in mixed case with the first letter lowercase, with the
first letter of each internal word capitalized.

Examples:

•
run();
•
runFast();
•
getBackground();

Additional rules:
The named of methods should follow common practice for naming getters
(getX()), setters (setX()), and predicates (isX(), hasX()).
Variables
Sun's naming guidelines states
Except for variables, all instance, class, and class constants are in mixed case with
a lowercase first letter. Internal words start with capital letters. Variable names
should not start with underscore _ or dollar sign $ characters, even though both
are allowed.
Variable names should be short yet meaningful. The choice of a variable name
should be mnemonic - that is, designed to indicate to the casual observer the
intent of its use. One-character variable names should be avoided except for
temporary "throwaway" variables. Common names for temporary variables are i,
j, k, m, and n for integers; c, d, and e for characters.
Examples:
•
int i;
•
char c;
•
float myWidth;
Constants
Sun's naming guidelines states

The names of variables declared class constants and of ANSI constants should be
all uppercase with words separated by underscores ("_").
Examples:
•
static final int MIN_WIDTH = 4;
•
static final int MAX_WIDTH = 999;
•
static final int GET_THE_CPU = 1;
Plug-ins and Extension Points
All plug-ins (and plug-in fragments), including the ones that are part of the Eclipse
Platform, like the Resources and Workbench plug-ins, must have unique identifiers
following the same style of naming convention as Java packages. For example, the
workbench plug-in is named org.eclipse.ui.
The names of a plug-in and the names of the Java packages declared within the code
library of that plug-in commonly align. For example, the org.eclipse.ui plug-in declares
much of its code in packages named org.eclipse.ui.* . While alignment is the
recommended practice, it is not an absolute requirement. For instance, the org.eclipse.ui
plug-in also declares code in packages named org.eclipse.jface.*. The org.eclipse.ant.core
plug-in declares code in packages named org.eclipse.ant.core and org.apache.tools.ant.*.
The plug-in namespace is managed hierarchically; do not create plug-in without prior
approval from the owner of the enclosing namespace.
Extension points that expect multiple extensions should have plural names. For example,
"builders" rather than "builder".
System Files and Settings
By convention, files or folders that start with a period ('.') are considered "system files"
and should not be edited by users or, directly, by other components that do not "own"
them.
Of special note is the ".settings" folder in a workspace project. This folder holds various
forms of preference or metadata specific to that workspace project. Files in this directory

do not have to start with a period (they are assumed "system files" as they are in a
"system folder") but they must follow the same naming conventions outlined elsewhere
in this guide. That is, they must identify themselves with their Eclipse Project's
namespace (e.g. org.eclipse.jdt, org.eclipse.jst, etc). and they should be as specific as
possible to denote the package they come from, or the function they are serving. For
example,
org.eclipse.jdt.core.prefs
org.eclipse.jst.common.project.facet.core.prefs
org.eclipse.wst.common.project.facet.core.xml
Two obvious exceptions to this convention are the .classpath and .project files, but ...
that's just because they were the first, before the large community of Eclipse was grasped.
Following these namespace guidelines will help avoid conflicts where two plugins or
projects could accidently pick the same name for a metadata file.
Eclipse User Interface Guidelines
(Version 2.1 - 3.x Working Draft)

Nick Edgar, Kevin Haaland, Jin Li and Kimberley Peter
Last Updated: February 2004
Note: Please use the discussion page to add comments instead of embedding them in this
document.

Note: We have created a section for hosting the drafts of ongoing Eclipse v3.x UI
guidelines (Best Practices) updates.
Go to Eclipse UI Best Practices v3.x updates (Last updated in June, 2006)
Notice
Your feedback can influence the ideas and guidelines described here. If you have
suggestions, please provide us with your feedback on the UI mailing list or on the
discussion page.
Introduction
In this document the Eclipse user interface guidelines are defined.

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™ 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.
The platform is very flexible and extensible, but this flexibility has a serious drawback. In
particular, there is no way within the program to ensure user interface consistency
between the registered components within the platform. This document attempts to
reconcile this problem, by defining standard user interface guidelines for the creation of
new components. 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.
These guidelines are intended for use by designers and implementors of an Eclipse user
interface extension.
The Workbench
To start out, let's take a look at the Eclipse workbench user interface, and the various
components within it.
The workbench is a collection of windows. Each window contains a menu bar, a toolbar,
a shortcut bar and one or more perspectives.

A perspective is a visual container for a set of views and content editors. The views exist
wholly within the perspective and are not shared, but any opened content editors are
shared across perspectives. 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. 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.
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..
In the File menu you will find a New submenu, which contains menu items for Project,
Folder, and File creation. 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. In the Edit
menu, you will find familiar commands like Cut, Copy, Paste, and Delete. 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. In the Project menu, you will find project related commands
such as Open project, Close project and Rebuild project are available. In the Run menu,
you will find commands related to running and debugging application code, and
launching external tools such Ant scripts. In the Window menu, you will find the Open
Perspective submenu to open different perspectives to suit to needs of your development
tasks. You will find perspective layout management menu items. You will also find the
Show View submenu to add views to the current Workbench window. In addition, you
will find the Preferences menu item, which is used to modify the functional preferences
of the Workbench.
As a plug-in developer, you can contribute new views, editors, wizards, menu, and tool
items to the platform. These contributions are defined using XML, and once registered,
integrate seamlessly with the components which already exist in the platform.
Projects, Folders and Files
Eclipse can be used to create many different kinds of content - Java files, Web content,
graphics, video - almost anything you can imagine. These objects are stored as regular
files within the Eclipse workspace. The workspace consists of one or more top level
projects. Each project contains a collection of folders and files. These objects are known
as resources.
Getting Started
For most developers, an introduction to the platform can be overwhelming, and you may
ask "where do I get started?". Here are a few basic guidelines which will help you.

This document is intended for UI designers and developers. With this audience in mind,
we can talk about the two main layers of any application: the model layer and the user
interface layer. In the model layer of Eclipse, known as the Workspace, is a collection of
resources (projects, folders and files). The user interface, or the Workbench, defines the
presentation for those resources.
As a UI developer, you will also have a model and a presentation. 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.
In Eclipse, an editor is used to contain the primary content, such as a document or data
object, which users interact with. In every case, this content is the primary focus of
attention and a reflection of the primary task. To illustrate this concept, let's look at some
common examples.
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. 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.
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. A view may be used to select an email message to read, and open an editor.
To communicate using instant messaging, the primary task is the conversation. The
primary focus is a particular conversation, so an editor is used to carry on that
conversation. A view may be used to list people with whom you can initiate a
conversation.
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.
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 (as an editor), and can
contribute commands to the workbench's main menu bar and toolbar.
A view may be used to save your favorite links, and reopen them. At any time, you may
decide to edit the page you are looking at. This causes a new editor to open. Views are

used to support the primary task. You use them to navigate a hierarchy of information,
open an editor, or view properties for the active part. Each view may have its own local
toolbar and local menu bar.
Once you have added a view or editor, an interesting question arises. Where did this
model come from? In Eclipse, most data is created using a creation wizard. 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.
All of these ideas will be discussed, in detail, in the following sections.

General UI Guidelines

This
It is a
Expe
You
s
recom
It is e
and A
forgiv
prere
Gu
Follo
consi
The
At its
single
diver
will b
If you

then t
Eclip
Eclip
lead t
curve
In som
"cust
an in
t
the be
Cons
Also
,
Gu
Follo
document de
a supplemen
rience, Mac
should conti
mmendations
expected tha
APIs, and the
veness, feed
equisite know
uideline 1.1
ow and apply
istency, forg
Spirit of E
s heart, Eclip
e team or by

rse sources. I
be positively
u're in doubt
the Java dev
pse for guida
pse. If so, ado
to greater co
e for your cu
me scenario
om" user int
tegrated env
enefit of pas
ult the Best
, visit the Ec
uideline 1.2
ow the platfo
efines UI gu
t to the othe
intosh Huma
inue to consu
s.
at you already
e basic UI de
dback, aesthe
wledge, plea

y good user i
giveness, feed
Eclipse
pse is a platf

y a partnersh
In either cas
y influenced
t about the a
velopment to
ance. In many
opt the platf
onsistency w
ustomers.
s, it may be
terface. This
vironment, w
st experience
Practices se
clipse platfor

orm lead for
uidelines that
r standard U
an Interface
ult those gui
y have a bas
esign princip
etics, and sim
se read the r
interface des
dback, aesth
form for tool
hip of teams,
e, the usabil

by user inte
appropriate lo
ooling and th
y cases, the
form's workf
with the platfo
tempting to
s interface w
where other to
e, and force y
ction for exa
rm newsgrou
user interfac
t are unique
UI guidelines
Guidelines,
idelines for b
sic understan
ples: user in
mplicity. If y
relevant docu
sign principl
hetics, and si
l plug-ins. Th
or the user m
ity of an ind
rface consist
ook and feel
he Plug-in De
workflow yo

flow and use
orm and othe
ignore the w
will almost ce
ools adopt th
your custom
amples and m
ups to share
ce conventio
and specific
s such as Mic
and Java Lo
basic UI des
nding of the
control, dire
you do not cu
umentation f
les: user in c
implicity.
hese plug-in
may assemb
dividual tool,
tency.
l for a tool, l
evelopment
ou imagine m
er interface c
er plug-ins,
workflow of
ertainly stand

he platform c
mers to learn
more inform
information
ons.
c to the Eclip
crosoft® Us
ook and Feel
ign and imp
Eclipse UI
a
ectness, cons
urrently have
first.
ontrol, direc
ns may be de
ble a set of pl
, and Eclipse
ook to the pl
Environmen
may already
conventions.
and an easie
Eclipse and
d out like a s
conventions
new ideas.
mation.
with the co
m

pse platform
ser
l Guidelines
lementation
architecture
sistency,
e the
ctness,
eveloped by
lug-ins from
e as a whole
latform first
nt (PDE) in
y exist in
This will
er learning
implement
sore thumb i
. You lose
mmunity.
m.
.

a
m
,
t,
a
in

If you
speci
by a s
indic
activa
Gu
Be ca
appli
Eclip
Eclip
Eclip
Visit
G
u
If you
better
Capi
u decide to r
ific UI conve
shaded title.
ate where th
ation in the w
uideline 1.3
areful not to
cation.
pse is an open
pse communi
pse a better p
www.eclips
uideline 1.4

u have an int
r platform fo
italization
reuse the con
entions. For
The use of s
he focus is, w
window.

mix UI met
n source pro
ity, write a p
platform for p
se.org and jo

teresting ide
or all.

nventions of
instance, the
shaded titles
within that pa
aphors. It m
oject. If you
proposal, and
product deve
oin the Eclip
ea, work with
f Eclipse, be
e active part

s within an e
art, but it wi
may blur the o
feel your ide
d work with
elopment an
se UI mailin
h the Eclipse
careful not t
in a workbe
editor (see be
ll also blur t
original conc
eas are gener
the Eclipse
nd increase c
ng list platfo
e community
to misapprop
ench window
elow) may b
the concept o
cept, and you
rally useful,
community
customer sati
orm-ui-dev.
y to make Ec
priate Eclips
w is indicated

e one way to
of part
ur own
join the
to make
isfaction.

clipse a
se
d
o



Cons
great
be ap
can b
Sente
group
label.
Gu
Use H
wind
wor
d
punct
Gu
Use S
those

first l
Lang
Eclip
reflec
shoul
separ
can b
Cons
G
u
Creat
Erro
If an
the e
r
Pleas
wizar
istent capita
er perception
pplied to all t
be used as a m
ence style ca
p labels. For
.
uideline 1.5
Headline sty
ows, dialogs
ds, and all no
tuation.
uideline 1.6

Sentence sty
e for check b
letter of the f
guage
pse is availab
ction of the d
ld be adopte
ration of all r
be translated
ult the Best
uideline 1.7
te localized v
or Handlin
error occurs
rror.
se refer to W
rd.
alization of te
n of quality.
titles, menus
menu item la
apitalization
r example, "C

yle capitaliza
s, tabs, colum
ouns, pronou

yle capitaliza
boxes, radio b

first word, a
ble on a varie
different lan
d for the tex
resources fro
to a new loc
Practices se

version of th
ng
s in Eclipse,
Wizards sectio
ext within a
Within a di
s, tooltip, tab
abel.
should be a
p
Choose an op
ation for men
mn headings
uns, adjective
ation for all c
buttons, grou
and any prop
ety of differe
guages and n
xt and image
om the sourc
cale.

ction for ex
a
he resources
the appropri
on for guidel
plug-in lead
ialog or wind
bs, and push
pplied to all
ption for the
nus, tooltip a
s and push bu
es, verbs and
control label
up labels, an
er names su
ent platform
numeric form
s within each
ce code of a
amples and m
within your
iate response
lines on how
ds to a more
dow, headlin
buttons. For
check boxes
e Java file" c
and all titles,

uttons. Capit
d adverbs. D
ls in a dialog
nd simple tex
ch as the wo
ms, in a variet
mats in each
h plug-in. Th
plug-in itsel
more inform
r plug-in.
e will be dep
w to handle u
polished fee
ne capitalizat
r example, "
s, radio butto
can be used a
, including th
talize the fir
Do not includ
g or window,
xt fields. Cap
ord Java.
ty of locales
h, a localizati
his involves
lf, so that tho
mation.
pendent on th

user input err
el, and
tion should
Run to Line
ons, and
as a group
hose used fo
rst and last
de ending
, including
pitalize the
. In
ion strategy
the
ose resource
he context o
rors in a
e"
or

es

of
Pleas
When
from
force
G
u
When

from
If a p
comm
work
platfo
The p
dialo
•
•
•
•
Gu
If a p
and lo

Vis
Go to
All v
Eclip
inform
graph
Follo
and th
eleme
are co
se refer to Ed
n an error oc
users, a mod
s the user to
uideline 1.8

n an error oc
users, comm
programming
municate the
kbench error
orm, uninsta
plug-in shou
g:
Provider n
Plug-in na
Plug-in ID
Version
uideline 1.9
programming
og it.
sual Des
o 3.x updates
isual user in
pse visual sty
mation, as w
hics in tools
owing these g
heir implem
ents include
overed in the
ditors section
ccurs which
dal dialog sh
o notice, and

ccurs which
municate the
g error occur
e occurrence
logging fac
i
all the corresp
uld provide th
name
ame (user fri
D

g error occur
ign
s
nterface elem
yle or Eclips
well as specif
based on the
guidelines w
mentation acro
s visual sem
e following
n for guideli
requires eith
hould be use
deal with th
requires eith
e occurrence
rs in the prod

to the user.
ility. This gi
ponding feat
he following
iendly name
rs in the prod
ments created
se style. In th
fications for
e Eclipse fra
will help ensu
oss the Eclip
mantic, style,
sections.
ines on how
her an explic
ed to commu
he problem.
her an explic
with a moda
duct, an erro
The error sh
ves the user
ture, and con
g information
e)
duct, commu
d for Eclipse
hese guidelin
implementin

amework.
ure consisten
pse tools and
and implem
to handle er
cit user input
unicate the er
cit user input
al dialog.
or dialog sho
hould also be
an opportun
ntact their sy
n in the deta
unicate the o
e follow a co
nes you will
ng Eclipse s
ncy of visual
d plug-ins. C
mentation con
rrors occur in
t or immedia
rror to the us
t or immedia
ould be used
e logged usin
nity to restar
ystem admin
ail area of the

occurrence w
mmon style
find basic
d
style icons an
l user interfa
Consistency o
nsiderations.
n an editor, .
ate attention
ser. This
ate attention
to
ng the
rt the
nistrator.
e error
with a dialog
called the
design
nd wizard
ace elements
of these
. These topic
.

,
s
cs
Con

In the
variet
select
In ord
tools,
graph

Icon
A gre
good
samp
carrie
consi
Gu
sistency
e developme
ty of concep
tion of tiny v
der to ensure
, and minimi
hical elemen
n Reuse
eat many ico
chance man
ple of the cor
es with it a s
istent meanin
uideline 2.1
ent of the Ec
pts in the use

visual signs
e a consisten
ize confusio
nts whenever
ons have alre
ny of the icon
re concepts i
specific mean
ng is mainta

lipse style ic
er interface. T
that many h
nt visual exp
on for the use
r possible.
eady been cr
ns or graphi
is shown in t
ning, so care
ained.
cons, a visua
These conce
have come to
erience, und
er, we encou
eated in the
cal elements
the following
e should be t

al language w
epts are now
o know throu
derstanding o
urage you to
Eclipse visu
s you may ne
g table. Each
taken when u
was formed t
represented
ugh using Ec
of concepts a
re-use Eclip
ual style so th
eed already e
h of these ele
using them t
to describe a
d by a large
clipse tools.
across the
pse style
here is a
exist. A
ements
to ensure tha
a
at

Re-us
Eclip

Icon
Vario
create
•
•
•

256
Eclip
stand
NOT
palett
ONL
Gu
Use t

se the core v
pse plug-ins.
n Palettes
ous palettes u
e the 3 differ
256 Color
of all icon
8 Color G
toolbar w
2 Color G
local toolb

Color Pal
pse style icon
dard colors an
TE: Although
te that come
LY the shown
uideline 2.2
the Eclipse 2
visual concep
used in creat
rent icon sta
r Palette for
n types
Grayscale P
wizard, and lo
Grayscale P
bar icons
ette
ns should be
nd 236 custo
h the color p
es with Adob
n color palet

256 color pal
pts to mainta
ting Eclipse
ates, as follow
r the active o
alette for th

ocal toolbar i
alette for th
designed us
om colors, a

palette shown
be Photoshop
tte should be
lette for crea
ain consisten
style icons.
ws:
or selected —
he enabled st
icons
he disabled st
sing a specia
s shown belo
n is based on
p, these two
e used when
ating the acti
nt representa
There are 3
— also referr
ate of perspe
tate of toolb
al 256 color p
ow.
n the standar

palettes are
creating Ecl
ive or selecte
ation and me
different pa
red to as "co
ective, view
ar, toolbar
w
palette that c
rd windows
NOT the sam
lipse style ic
ed state of al
eaning across
alettes used t
olor"— state
, toolbar,
wizard, and
consists of 2
.aco color
me and
cons.
ll icon types
s
to
20
s.

8 Co

To cr
anoth

Gu
Use t
toolb

2 Co
To cr
to use

Gu
Use t
and lo

Icon
The E
optim
these
olor Grays
reate graysca
her palette th
uideline 2.3
the Eclipse 8
ar wizard, an
olor Grays
reate graysca
e a subset of
uideline 2.4
the Eclipse 2

ocal toolbar
n Types
Eclipse style
mized for its
e types and w
scale Palet
ale, enabled
hat consists o

8 color palett
nd local tool
scale Palet
ale, disabled
f the 8 color


2 color palett
icons.
e icons have
specific loca
where they ar
tte
versions of y
of the 8 colo
te for creatin
lbar icons.
tte
d versions of
palette, that
te for creatin

been catego
ation within
re located.
your full col
rs shown be
ng the enable
f your full co
t consists of t
ng the disabl
orized into se
the user inte
lor icons, yo
elow:

ed state of p
olor and enab
the 2 colors
led state of t
eparate types
erface. Below
ou will need
erspective, v
bled icons, y
shown below
oolbar, toolb
s so that each
w is a breakd
to use
view, toolbar
you will need

w:
bar wizard,
h can be
down of
r,

d



A
Product
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.
B
Perspective and Fastview
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.
C
Toolbar
Toolbar icons are found on the main toolbar across the top of the workbench. These icons
invoke an command, either globally or within the editor.
D
Toolbar Wizard
Toolbar wizard 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.
E
View

View icons are found on the left side of the titlebar of each view within the workbench.
These icons indicate each view’s function.
F
Local (View) Toolbar
Local toolbar icons are found to the right of the view icon on the titlebar of each view
within the workbench. These icons invoke an command on objects in that view only.
Loca
menu
G
M
Mode
work
H
Ob
Objec
corne
Gu
Use t

Icon
With
Withi
vertic
withi
icons
The d
prope
l toolbar ico
us.
Model Object

el Object ico
kbench (such
bject Overla
ct overlay ic
ers of model
uideline 2.5
the appropria
n Size & Pl
few excepti
in that area,
cal and horiz
in the interfa
s are cut with
diagrams bel
er placement
ons are also f
t
ons are found
h as files, fold
ay
cons are also
object icons

ate icon type
lacement
ions, Eclipse
a 15 x 15 pi
zontal line of
ace. Note the
h the specific

low show th
t within the a

found in all m
d in tree view
ders, project
o found in tre
s as signifier
e in the locat
e style icons
ixel space is
f empty pixe
e location of
c placement
e proper sizi
allotted scre
View Ico
Maximum
centered.
Empty pi
menus, inclu
ws, list view
ts and so on)
ee or list view
rs of some so
tion it is desi
are designed
reserved for
els to allow f
f the empty p

shown to en
ing of the se
een space.
ons
m 16 pixels w
xels must be
uding main, p
ws, and on Ed
).
ws. They are
ort of change
igned for wi
d within an a
r the image i
for proper pl
pixels in the
nsure alignm
eparate types
wide x 16 pi
e on the left,
pull down, a
ditor Tabs w
e appended t
e.
ithin the user
area of 16 x
itself, leavin
lacement of
samples belo
ment in the us

s of icons, an
ixels high, al
and bottom
and context
within the the
to the variou
r interface.
16 pixels.
ng both a
the image
ow. The
ser interface
nd their
lways
m.
e
us

e.
Gu
Follo
Gu
uideline 2.6
ow the specif
uideline 2.7

fic size speci

Perspecti
Fastview
Maximum
centered.
Empty pi
Toolbar
Toolbar
Local To
Maximum
centered.
Empty pi
Model O
Maximum
centered.
Model Ob
high.
Ob
ject O
Object Ov
pixel size
Maximum
Icon shou
separate i
See the n
keyline o
ifications for
ive Icons
w Icons

m 16 pixels w
xels must be
Icons
Wizard Ico
oolbar Icons
m 16 pixels w
xels should
Object Icons
m 16 pixels w
bject icons m
Overlay Icon
verlays are o
e.
m 7 pixels w
uld have a w
it from the ic
ext section o
n different ty
r each type o
wide x 16 pi
e on the righ
ns
s
wide x 16 pi
be on the lef
wide x 15 pi
must be no g
ns
one of the ex
wide x 8 pixe

white outside
con it is bein
on Icon Posit
ypes of Obje
of icon.
ixels high, al
ht, and bottom
ixels high, al
ft, and top.
ixels high, al
greater than 1
xceptions to
ls high, alwa
keyline arou
ng appended
tioning for u
ect Overlay
lways
m.
lways
lways
15 pixels
the 16 x 16
ays centered
und it to
d to.
using the
icons.
d.

Cut the icons with the specific placement shown to ensure alignment in the user interface.


Icon Positioning
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.)

Overview


1. Toolbar icons
(Includes Toolbar and Toolbar Wizard Icons)



Item Positioning and Spacing
A
Toolbar 22 pixels high
B
Between left margin and handle 4 pixels
C
Between handle and first icon 7 pixels
C
Between icon and top of toolbar 3 pixels
C
Between icon and bottom of toolbar 3 pixels
C
Between icon and twisty 7 pixels

D
Between twisty and hard rule 7 pixels
E
Between hard rule and icon 6 pixels
F
Between icons 7 pixels
G
Between icon and hard rule 10 pixels
H
Between hard rule and handle 2 pixels

2. Titlebar icons
(Includes View and Local Toolbar Icons)



Item Positioning and Spacing
A
Title bar 22 pixels high
B
Between left margin and view icon 4 pixels
B
Between view icon and text label 3 pixels
B
Between title bar icons and top of title bar 3 pixels
B
Between title bar icons and bottom of title bar 3 pixels
C
Between local toolbar icons 7 pixels
D

Between last local toolbar icon and closing
window 'x'
7 pixels
E
Between closing window 'x' and right margin 4 pixels
3. Perspective icons
(Includes Perspective and Fastview Icons)
Perspective Icons

Item Positioning and
Spacing
A
Perspective bar 27 pixels wide
B
Between left margin and
icon
5 pixels
B
Between icon and right
margin
6 pixels
B
Between top of
perspective section and
first icon
3 pixels
B
Between icon and hard
rule
6 pixels

C
Between hard rule and
top of icon
6 pixels
D
Vertically between icons 6 pixels
E
Between icon and hard
rule
6 pixels
Fastview Icons

Item Positioning and
Spacing
D
Vertically between icons
(same as perspective
icons)
6 pixels
E
Between icon and hard
rule
6 pixels
F
Between left margin and
icon
5 pixels
F
Between top of fastview
section and first icon

3 pixels
F
Between icon and right
margin
6 pixels
4. Tree View icons
(Model Object Icons)



Item Positioning and Spacing
A
Between “+/-” widget and left of window 4 pixels
A
Between “+/-” widget and top of window 4 pixels
B
Between top of window and first icon 0 pixels
B
Vertically between icons 0 pixels
B
Between horizontal treeview branch and icon 0 pixels
B
Between icon and text label 3 pixels
C
Text is nested within the text label 3 pixels each on left and
top, 2 pixels on right, 4
pixels on bottom (length
varies)

Icon Overlays

As stated under Icon Size & 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.
Project Nature Overlay
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.
Only a few project nature overlay icons have been created to prevent crowding in the
interface. Project nature overlays quickly identify the various types of projects that can
be contained in the Navigator and mirroring views.